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

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


> > 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?

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.

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.


Alex