[Python-Dev] Half-baked proposal: * (and **?) in assignments
Mon, 25 Nov 2002 08:52:48 +0100
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.