[Python-Dev] Single- vs. Multi-pass iterability

[Guido van Rossum]

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