> 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4