> None of my code uses explicit use of iterators, and I was very > aware of them. My new code that I'm building now does, but it > wouldn't take much effort to fix it. I myself personally would > rather keep Python "clean" of blemish. For the most part, > Python is really free of dragons and that's why I like it. I'm > willing to put up with short-term pain for long term gain. Unlike > Java or Visual Basic, I intend to be programming in Python 10+ > years from now; so from my perspective, it is an investment. Calling it a dragon sounds way overstated. Another issue is that we can't really fix this retroactively in Python 2.2. Python 2.2 has been elected to be the "Python-in-a-Tie" favored by the Python Business Forum, giving it a very long life expectancy -- 18 months from the first official release of Python-in-a-Tie (probably Python 2.2.2), plus however long it takes people to want to ulgrade after that. > Plus, most features don't get used by the public for at least > a year or so as it takes a while for the code-examples to > start using them and books to be updated. > > | Care to conduct a survey on c.l.py? > > Sure. I'll run the survey and report back. What would > be the options? It'll be a simple CGI form using a radio > or check boxes and a button. I'll aggregate the results. > To do this I need: > > - A specific description of what would change > - An example of what would break, plus what it would > be replaced with. > - An explanation of what problems occur when the > blemish isn't fixed (what can't you do?) - The mapping between the next() method and the tp_iternext slot in the type object would disappear, and instead the __next__() method would be mapped to this slot. This means that every iterator definition written in Python has to be changed from "def next(self): ..." to "def __next__(self): ...". - There would be a new built-in function, next(), which calls the __next__() method on its argument. - Calls to it.next() will have to be changed to call next(it) instead. (it.__next__() would also work but is not recommended.) - There really isn't anything "broken" about the current situation; it's just that "next" is the only method name mapped to a slot in the type object that doesn't have leading and trailing double underscores. --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