A really bad idea.

[Russell E. Owen]

In article <c0abefc3.0211140738.635c0e6d at posting.google.com>,
 marvelan at hotmail.com (M) wrote:

>The new enumerate or zip function. If you look at the code using this function 
>it is not at all obvious what the code does...Generators 
>are another thing that are just horrible. They just don't work in a way
>that one would expect from previous experience.

I agree with some of this and am always glad to see discussions like 
this. I hope you don't get too many dismissive replies -- they often 
seem to surface when one discusses warts.

I think generators were done rather poorly in that there is no special 
statement to indicate a generator (something many of us lobbied for at 
the time). As a result you have to look through the code to see whether 
it's a function or a generator, looking for that magic "yield" statement 
-- which can be quite buried, especially in a long function (or is that 
a generator? damn!).

As a concept, I feel generators and iterators are well worth learning 
and using. I make pretty heavy use of them and am glad to be saving 
myself the code I'd otherwise have to write. On the other hand:
- There is some area of all this I still find confusing. it's hard to 
put my finger on, but I'm not always sure whether I should be obtaining 
an iterator and then using it in a for loop or defining __iter__ (or is 
it iter?) and using my object directly in a for loop. Also, I'm not 
always sure about iterators or generators that call iterators or 
generators.
- Iterators have some nasty pitfalls. For instance on a file you cannot 
reliably do this:
# read some data
for line in file:
  # process the data, break partway through
# read more data:
for line in file: (or maybe that works but file.readline() will not)
You will often lose data--the first "for" loop reads ahead for 
efficiency and the later read misses all that data.


Map, reduce and their ilk are quite specialized. I usually (but not 
always) find that using them makes my code harder to understand, 
probably due to the need to pass in a function. I suspect a big reason 
they're in the language is they're so much faster than doing the same 
jobs with other constructs. 

On the other hand, I like zip just fine (though I lament the lack of an 
unzip counterpart). I find it simple and straightforward, though it's 
not something I use every day.

Another wart, in my mind, is that map and zip (which are closely 
related) handle a set of lists of nonequal lengths in different ways. 
I'd much rather have seen consistency between them, and preferably a way 
to specify a modifier to get the other behavior (for lists of unequal 
lengths). The lack of consistency is all the more surprising to me 
because zip was introduced fairly recently, long after map was well 
established.


How do you feel about list comprehensions? To me they look a bit like 
line noise, but I love them and use them heavily. them. I find myself 
wshing there was a similar construct for creating dictionaries.

-- Russell