[Python-Dev] accumulator display syntax

Skip Montanaro skip at pobox.com
Tue Oct 21 12:34:24 EDT 2003

    >> Here's an alternate suggestion.  Instead of inventing new syntax, why
    >> not change the semantics of list comprehensions to be lazy?  

    Alex> Well, yes, the _most_ one could ever have to change is move from [
    Alex> ... ] to list[ ... ]) to get back today's semantics.  But any use
    Alex> NOT so changed may break, in general; any perfectly correct
    Alex> program coded with Python 2.1 to Python 2.3 -- several years'
    Alex> worth of "current Python", by the time 2.4 comes out -- might
    Alex> break.

I understand all that.  Still, the "best" syntax for these so-called
iterator comprehensions might have been the current list comprehension
syntax.  I don't know how hard it would be to fix existing code, probably
not a massive undertaking, but the bugs lazy list comprehensions introduced
would probably be a bit subtle.

Let's perform a little thought experiment.  We already have the current list
comprehension syntax and the people thinking about lazy list comprehensions
are seem to be struggling a bit to find syntax for them which doesn't appear
cobbled together.  Direct your attention to Python 3.0 where one of the
things Guido has said he would like to do is to eliminate some bits of the
language he feels are warts.  Given two similar language constructs
implementing two similar sets of semantics, I'd have to think he would like
to toss one of each.  The list comprehension syntax seems the more obvious
(to me) syntax to keep while it would appear there are some advantages to
the lazy list comprehension semantics (enumerate (parts of) infinite
sequences, better memory usage, some performance improvements).

I don't know when 3.0 alpha will (conceptually) become the CVS trunk.  Guido
may not know either, but it is getting nearer every day.  Unless he likes
one of the proposed new syntaxes well enough to conclude now that he will
keep both syntaxes and both sets of semantics in 3.0, I think we should look
at other alternatives which don't introduce new syntax, including morphing
list comprehensions into lazy list comprehensions or leaving lazy list
comprehensions out of the language, at least in 2.x.  As I think people
learned when considering ternary operators and switch statements, adding
constructs to the language in a Pythonic way is not always possible, no
matter how compelling the feature might be.  In those situations it makes
sense to leave the construct out for now and see if syntax restructuring in
3.0 will make addition of such desired features possible.

Anyone for

    [x for x in S]L

? <lazy wink>


More information about the Python-Dev mailing list