[Python-Dev] Half-baked proposal: * (and **?) in assignments

Brett Cannon bac@OCF.Berkeley.EDU
Sun, 24 Nov 2002 16:14:16 -0800 (PST)

[Armin Rigo]

> I've always felt it counter-intuitive and even confusing that lists and dicts are built-in types with
> methods, whereas iterators are just an expected interface with no user-visible methods apart from
> 'next', which is also a magic name (a magic name with no __??).

What have people found with newbies and their comprehension of iterators?
I ran into one person who has recently taught  himself Python and didn't
know what an iterator was.  How much promotion of iterators is occuring
out in the community?

> The lack of common implementational part between iterator forces us to use a module to collect useful
> operations, which goes against the current everything-as-a-method trend.
> I wish we would have a standard built-in 'iter' type with a standard set of methods, instead of the
> current 'iter(x)' which is essentially just 'x.__iter__()' and returns anything. If 'iter' were a
> built-in type it could provide additional methods, e.g.
>    a, b, c = iter(x).peel(2)
> as an equivalent to the proposed iterator-returning 'a,b,*c=x'.

Interesting thought.  One reason I can think of it not being considered a
built-in type is that iterators (at least to me) are wrappers around an
existing type.  I view built-in types as fundamental and as bare-bones as
you care to go; iterators sit at a level above that.

> A similar option would be to require that iterator objects be instances of subtypes of 'iter'. Well,
> it's probably too late to change that kind of thing anyway.

Not necessarily.  Something like this could be done with this iterator
module idea.  Could have a class in there that iterators could subclass.
Problem with that is that iterators can be generators and those are not
classes at all (I take the "generators are pausable functions" view).

There  is always Python 3.  =)