[Python-Dev] accumulator display syntax

Alex Martelli aleaxit at yahoo.com
Fri Oct 17 17:54:32 EDT 2003


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




More information about the Python-Dev mailing list