Python is faster than C

[Robert Brewer]

Armin Rigo wrote:
> This is a rant against the optimization trend of the Python 
> interpreter.
> ...Iterators, for example, are great in limited cases
> but I consider their introduction a significant complication in the
> language; before, you could expect that some function from which you
> would expect a sequence returned a list.  Python was all lists and
> dicts, with dicts used as namespaces here and there.  
> 
> >>> enumerate([6,7,8,9])         # uh ?
> <enumerate object at 0x401a102c>
> 
> enumerate() should return a normal list, and
> it should be someone else's job to ensure that it is 
> correctly optimized
> away if possible (and I'm not even talking about Psyco, it 
> could be done
> in the current Python implementation with a reasonable amount of
> effort).

I'd like to think I'm not understanding your point, but you made it so
danged *clear*.

Enumerate should absolutely *not* return a normal list. The use case I
think you're missing is when I do not want the enumeration optimized at
all; I want it performed on-the-fly on purpose:

for i, line in enumerate(file('40GB.csv')):
    if i % 600000:
        do_special()
    else:
        do_normal()

Forcing enumerate to return a list would drag not only the entire
40GB.csv into memory, but also the entire set of i. Using an iterator in
this case instead of a list *is* the optimization.

> I know you can always do list(_).  My point is that this is a
> user-visible optimization.

Iterators are not lists and shouldn't be confused/substituted with them.
The use cases are by no means limited; I have thousands of lines of code
which use iterators, not lists, precisely for their differences. If you
want a list instead of an iterator, this _should be_ user-visible.


Robert Brewer
MIS
Amor Ministries
fumanchu at amor.org