librelist archives

« back to archive

Python slice notation?

Python slice notation?

From:
Steve Freitas
Date:
2010-08-19 @ 20:57
  Hi Mariano,

Love what you're doing with efene/ifene. (Especially the arrow operator 
-- I sure could use that in a few other languages!) Any chance we could 
get Python's slice notation for getting subsets of lists, etc? I miss it 
terribly when I'm not able to use Python.

Steve

Re: [efene] Python slice notation?

From:
Mariano Guerra
Date:
2010-08-20 @ 21:29
On Thu, Aug 19, 2010 at 5:57 PM, Steve Freitas <sflist@ihonk.com> wrote:
>  Hi Mariano,
>
> Love what you're doing with efene/ifene. (Especially the arrow operator
> -- I sure could use that in a few other languages!) Any chance we could
> get Python's slice notation for getting subsets of lists, etc? I miss it
> terribly when I'm not able to use Python.

I thought about that, but slicing lists in erlang is costly, the
correct way to do it(TM) is to use the [Head:Tail] idiom to process
the head and continue with the tail recursively. If I add slice
notation then people will think that since it's built in it may be
fast, and will make people write algorithms in a way that hurts
performance.

Then I will have to explain why slicing is so slow ;)

BTW I really like slicing too :)

Re: [efene] Python slice notation?

From:
Steve Freitas
Date:
2010-08-23 @ 23:01
  On 08/20/2010 03:29 PM, Mariano Guerra wrote:
> I thought about that, but slicing lists in erlang is costly, the
> correct way to do it(TM) is to use the [Head:Tail] idiom to process
> the head and continue with the tail recursively. If I add slice
> notation then people will think that since it's built in it may be
> fast, and will make people write algorithms in a way that hurts
> performance.
>
> Then I will have to explain why slicing is so slow ;)
>
> BTW I really like slicing too :)

Please allow me to persuade you otherwise! :-) There are plenty of ways 
to hurt performance in all the programming languages we use. It would be 
a fair bet to say that on most projects, most lines of code are not 
performance critical. And the performance critical stuff? Well, we know 
that we may have to throw out our preconceived notions about what is 
fast and slow and be guided purely by profiling. Slow slicing wouldn't 
change any of this. And there would be nothing wrong with placing a 
caveat in the manual so you only have to explain it once. :-)

Steve