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/)