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