Joachim König <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] http://rhodesmill.org/brandon
_______________________________________________
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
