[Python-3000] Builtin iterator type

George Sakkis gsakkis at rutgers.edu
Tue Nov 14 05:36:25 CET 2006


On 11/13/06, Guido van Rossum <guido at python.org> wrote:

> On 11/13/06, George Sakkis <george.sakkis at gmail.com> wrote:
> > On 11/13/06, Guido van Rossum <guido at python.org> wrote:
> >
> > > As my final word, I think this is a seriously bad idea, and as you're
> > > not answering my challenge about duck typing I don't think you
> > > understand your own proposal.
> >
> > I think I do, though I can't tell the same about the reasons of your
> > objections to it. In your previous reply you mentioned that I need to
> > have a more technical argument to convince you, and that's why I chose
> > to reply with the most technical argument, a proof of concept
> > implementation that addresses your concerns about how to incorporate
> > the itertools functions as methods.
> >
> > As for the duck typing, I mentioned already that nobody forces you to
> > extend this type to make some class an iterator, as nobody forces you
> > to extend dict or dictmixin to write a user-defined mapping. You may
> > well start from scratch implementing just next(); if you don't plan to
> > use "+", "*" or any of the itertools operations on this type,
> > extending Iter is useless. If you do plan to provide these operations
> > though, you may either write them from scratch every time, or extend
> > Iter.
> >
> > I honestly fail to understand your current objections. Is my analogy
> > with dictmixin flawed ? Would anything change if I named it
> > "itermixin" instead of iter or Iter ? I'm ok with the idea being
> > rejected, but at least I'd like to understand the reasons.
>
> The flaw is that you're creating two categories of iterators: those
> that support the various methods you're adding, and those that don't.
> This means that the itertools module can't be discarded, because it is
> still needed to support those operations for the iterators that don't
> have them natively. Thus, you're introducing two ways of doing the
> same thing -- using itertools (works for all iterators) or using the
> methods (only works for iterators that inherit from your base class).

Understood. Any _technical_ reasons then why shouldn't all iterators
inherit from it, or "duck typing is The Right Way" should be taken as
axiom ? Why do we somehow _need_ itertools when we don't need
sequencetools, mappingtools, etc ? What's special about the iterator
protocol ?

George


More information about the Python-3000 mailing list