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

Armin Rigo arigo@tunes.org
Sun, 24 Nov 2002 06:05:38 -0800 (PST)

On Sun, Nov 24, 2002 at 11:12:51AM +0100, Alex Martelli wrote:
> > I think the question becomes whether we want to start adding modules that
> > service specific language abilities like generators.  We have the string
> > module, but that is on its way out (right?).  There is no module for list,
> > dict, or tuple tricks or helper functions.  There is also no module for
> No, but that's because lists and dicts (and strings) package their 
> functionality up as methods, so there's no need to have any supporting 
> module.

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 __??).

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'.

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.