[Python-3000] [Python-Dev] Python 3000 Status Update (Long!)

Brandon Craig Rhodes brandon at rhodesmill.org
Tue Jun 19 16:43:40 CEST 2007


Joachim König <him at online.de> writes:

> ... could someone enlighten me why
>
> {,}
>
> can't be used for the empty set, analogous to the empty tuple (,)?

And now that someone else has broken the ice regarding questions that
have probably been exhausted already, I want to comment that Python 3k
seems to perpetuate a vast asymmetry.  Observe:

(a) Syntactic constructors

 [ 1,2,3 ]   works
 { 1,2,3 }   works
 { 1:1, 2:4, 3:9 }   works

(b) Generators + constructor functions

 list(i for i in (1,2,3))   works
 set(i for i in (1,2,3))   works
 dict((i,i*i) for i in (1,2,3))   works

(c) Comprehensions

 [ i for i in (1,2,3) ]   works
 { i for i in (1,2,3) ]   works
 { i:i*i for i in (1,2,3) ]   returns a SyntaxError!

This seems offensive.  It spells trouble for new students, who will
have to simply memorize which of the three syntactically-supported
containers support comprehensions and which do not.  It spells trouble
when trying to explain Python to seasoned programmers, who will think
that they detect trouble in a language that breaks obvious symmetries
over something so basic as instantiating container types.

The PEP for dictionary comprehensions, when I last reviewed it, argued
that dict comprehensions are unnecessary, because we have generators
now.  It seems to me that either:

 1) The grounds for rejecting dict comprehensions are valid, and
    therefore should be extended so that everything in (c) above goes
    away.  That is, if generators + built-in constructor functions are
    such a great solution for creating dicts, then list comprehensions
    and set comprehensions should both go away as well in favor of
    generators.  The language would become simpler, the parser would
    become simpler, and Python would be easier to learn.

 2) The grounds for rejecting dict comprehensions are invalid, so they
    should be introduced in Python 3k so that everything in (c) works.

Given that Python 3k is making such strides in other areas where cruft
and asymmetry needed to be removed, it would seem a shame to leave the
container types in such disarray.

-- 
Brandon Craig Rhodes   brandon at rhodesmill.org   http://rhodesmill.org/brandon


More information about the Python-3000 mailing list