[Python-Dev] Features for Python 2.0

[Guido van Rossum]

> Sometimes
> 
> c = a
> a += b
> assert  a is c
> 
> fails, and sometimes not, depending on a's type. This is just begging
> for trouble. Maybe it will cause massive confusion, maybe it won't. I know
> I'll usually be wary of using it.

Don't worry about this.

Python doesn't guarantee the semantics for 'is' independent on the
type anyway.  E.g.:

  a = b[:]
  assert a is b

may fail or succeed depending on the type (try it with strings, tuples
and lists).

> List comprehensions' problems is that we cannot find a syntax that we all
> agree is readable. Perhaps the answer is not list comprehensions, but
> lexical scoping combined with steroid versions of map and filter, together
> with zip to bind things together. 

I'm about 3000 messages behind in that particular discussion.  I still
really like Greg Ewing's original syntax:

  [x for x in seq]

with extensions to

  [x+y for x in seq1 for y in seq2]
  [x for x in seq if pred(x)]
  [x, x*2 for x in seq]

(General meta-comment on PEPs: these long intros explaining the
problem are a detriment to finding the actual proposal.  Perhaps we
could have a one-paragraph explanation for the need, then a concrete
proposal, then motivation and rationale and background, and then
raised objections plus responses?  Currently the rationale seems to be
coming up front, which distracts from the proposal.)

--Guido van Rossum (home page: http://dinsdale.python.org/~guido/)