On Friday 17 October 2003 10:20 pm, Skip Montanaro wrote: ...
Alex> Neither: it returns an iterator, _equivalent_ to the one that Alex> would be returned by _calling_ a generator such as
Alex> def xxx(): Alex> for x in S: Alex> yield x
All the more reason not to like this. Why not just define the generator function and call it?
The usual problems: having to use several separate statements, and name something that you are only interested in using once, is a bit conceptually cumbersome when you could use a clear inline expression "right where you need it" for the same purpose. Moreover, it seems a bit strange to be able to use the well-liked comprehension syntax only at the price of storing all intermediate steps in memory -- and have to zoom up to several separate statements + a name if you'd rather avoid the memory overhead, e.g.: sum( [x+x*x for x in short_sequence if x >0] ) is all right, BUT if the sequence becomes too long then def gottagiveitaname(): for x in long_sequence: if x>0: yield x+x*x sum( gottagiveitaname() ) That much being said, I entirely agree that the proposal is absolutely NOT crucial to Python -- it will not enormously expand its power nor its range of applicability. I don't think it's SO terribly complicated to require application of such extremely high standards, though. But if the consensus is that ONLY lists are important enough to deserve the beauty of comprehensions, and EVERY other case must either pay the memory price of a list or the conceptual one of calling and then invoking a one-use-only generator, so be it, I guess.
While Perl sprouts magical punctuation, turning its syntax into line noise, Python seems to be sprouting multiple function-like things. We have
* functions * unbound methods * bound methods * generator functions * iterators (currently invisible via syntax, but created by calling a generator function?) * instances magically callable via __call__
Every one of these was in Python when I first met it, except generators -- and iterators, which are NOT function-like in the least, nor "invisible" (often, an iterator is an instance of an explicitly coded class or type with a next() method). You seem to have forgotten lambda, though -- and classes/types (all callable -- arguably via __call__ in some sense, but you could say just the same of functions &c). Which ALSO were in Python when I first met it. So, I see no "sprouting" -- Python has "always" (from my POV) had a wide variety of callables.
and now this new (rather limited) syntax for creating iterators.
...which isn't function-like either, neither in syntax nor in semantics. Yes, it's limited -- basically to the same cases as list comprehensions, except that (being an iterator and not a list) there is no necessary implication of finiteness.
I am beginning to find it all a bit confusing and unsettling.
I hear you, and I worry about this general effect on you, but I do not seem to be able to understand the real reasons. Any such generalized objection from an experienced Pythonista like you is well worthy of making everybody sit up and care, it seems to me. But exactly because of that, it might help if you were able to articulate your unease more precisely. Python MAY well have accumulated a few too many things in its long, glorious story -- because (and for good reason!) we keep the old cruft around for backwards compatibility, any change means (alas) growth. Guido is on record as declaring that release 3.0 will be about simplification: removing some of the cruft, taking advantage of the 2->3 bump in release number to break a little bit (not TOO much) backwards compatibility. Is Python so large today that we can't afford another release, 2.4, with _some_ kind of additions to the language proper, without confusing and unsettling long-time, experienced, highly skilled Pythonistas like you? Despite the admirable _stationariety_ of the language proper throughout the 2.2 and 2.3 eras...? If something like that is your underlying feeling, it may be well worth articulating -- and perhaps we need to sit back and listen and take stock (hey, I'd get to NOT have to write another edition of the Nutshell for a while -- maybe I should side strongly with this thesis!-). If it's something else, more specific to this set of proposals for accumulators / comprehensions, then maybe there's some _area_ in which any change is particularly unwelcome? But I can't guess with any accuracy... Alex