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

[Brett Cannon]

[Alex Martelli]

> On Monday 25 November 2002 01:14 am, Brett Cannon wrote:
>    ...
> > 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.
>
> list and dict are full of helpful "convenience" methods, some of which supply
> handier ways to perform operations for which there would also be other ways,
> e.g. alist.extend(another) as a readable equivalent of
> alist[len(alist):]=another and so on.  Thus I don't understand what you mean
> by "fundamental and bare-bones" in this context.
>

In other words the data structures is not built off of something else.
You can't get much simpler than a list, tuple, or string (yes, you don't
need dicts, but they are wonderful things and basic to almost any major
program).  Iterators, though, are built off of something, and thus are not
"bare-bones".  It isn't about  the methods as much as what is used to
create the data structure.

>
> > > 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).
>
> I don't see any problem (besides the SMOP of making it so) with ensuring that
> a generator, when called, returns an instance of (whatever subclass of) iter.
> Being "not classes at all" is a strange objection.  After:
>     x = somegenerator()
> x is an object of a system-determined type (and type==class, in perspective),
> so why coulnd't the system choose to have that type be a subtype of iter?
>

I guess you could do that, but  as you point out below, I don't want to
require subclassing by having generators turn into some special iter type.

> What WOULD be intolerable, it appears to me, would be to *require* that
> user-coded iterators (classes exposing currently-suitable __iter__ and next
> methods) MUST subclass iter.  That would break existing, running code, and go
> against the grain of Python, which nowhere else imposes such requirements.
> Having a (mix-in?) class that iterators COULD subclass (as Brent suggests) is
> one thing; for Python to REQUIRE such subtyping (as Armin appears to wish
> could be done) is quite another.
>

Here here!  I am slowly being sold on this iterator module idea.

> Currently Python tends to supply extra optional functionality in modules, not
> packaged up as mix-in classes but rather as functions.  For example, lists
> don't subclass a "Bsearchable" mix-in to get binary search capabilities;
> rather, module bisect supplies useful polymorphic functions.  There is no
> need to subclass any "Shuffleable" class for a sequence to be subjected to
> shuffling: rather, module random supplies the useful polymorphic function
> shuffle.  I like this general approach and I don't see why it should be
> abandoned for supplying useful polymorphic functionality on iterators.
>

OK, so it is starting to sound like a module that collects well-coded
iterator code is a good thing.  Perhaps a deferred PEP could be started
that collected the suggested code to be included in the module?  Or
perhaps a patch on SF (or even a project)?  That way this idea doesn't
slip through the cracks for any reason and the rest of the Python
community will hear about this and start thinking about it.  People would
also get the benefit of the code now instead of having to wait until
Python 2.(>=4) to get the code.

-Brett