> While agreeing that caution is prudent, this specific reason is a poor one: > I didn't read the PEP like "a user", but like a standards geek. It never > occurred to me that a once-open issue would be resolved *only* in an > addendum without the resolution also being reflected back into the main > text. So I read the main text carefully, but barely even noticed the > existence of the rest. On a Bell curve, I expect that way of reading a PEP > is hugging a tail. I guess the true meaning of the term "BDFL Pronouncement" hasn't quite sunk in with you. :-) > > ... > > I'd say that *if* there's a useful use of this, we shouldn't break > > that in the 2.2 branch. 2.3 is a different issue. > > If Marc-Andre hasn't complained yet, there's no use at all for it <wink>. OK, on to practicalities. While preparing a patch, I discovered something strange: despite the fact that listiter_next() never raises StopIteration when it returns NULL, and despite the fact that it is used as the implementation for the next() method, calling iter(list()).next() *does* raise StopIteration, rather than a complaint about NULL without setting an exception condition. It took a brief debugging session to discover that in the presence of a tp_iternext function, the type machinery adds a next method that wraps tp_iternext. Cute, though unexpected! It means that the implementation of various iterators can be a little simpler, because no next() implementation needs to be given. --Guido van Rossum (home page: http://www.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