[Python-Dev] Half-baked proposal: * (and **?) in assignments
Sun, 24 Nov 2002 16:07:36 -0800 (PST)
> On Sunday 24 November 2002 10:34 am, Brett Cannon wrote:
> > Actually, with the way it is coded, you would want arg_cnt defaulting to
> > 1; it is meant to represent the number of arguments sans the one the
> > iterator is being assigned to.
> Right -- sorry, I let the parameter's name fool me, without checking more
> carefully. Maybe renaming it to number_of_splits or something like that
> would help the somewhat-careless reader;-).
=) This is what happens when you just code and post on a whim. =)
> > And I didn't know ``iter()`` just returned its argument if it was already
> > an iterator. Should have, though, since all other constructor methods are
> > like that (e.g. dict(), list(), etc.).
> Hmmm, not really: list(L) returns a list L1 such that L1 == L but id(L1) !=
> id(L) -- i.e., list and dict give a *shallow copy* of their list and dict
> argument respectively. iter is different...
Oops. Rather cool, though, since that is a nice way to copy a list just
like the [:] trick.
> > 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. Tuples don't need anything special. Generic iterators do not offer
> pre-cooked rich functionality nor do they have methods usable to locate
> such functionality, yet clearly they could well use it, therefore a module
> appears to be exactly the right place to locate such functionality in.
True, but there are possible things that are handy but you don't want to
have as a full-blown method (and of course because I have said this no
example is coming to my mind).
I guess I just have not come up with that many fancy tricks for iterators
that would fill a module. The only other thing I have found handy is a
wrapper function that keeps copies of what an iterator returns so you can
index the result later; memoization for iterators.
> There's no need to distinguish generators from other iterators in this
> respect; generators are just one neat implementation of iterators.
I totally agree with that assessment. Generators have always been a handy
way of writing ``__iter__()``. This is one of the "cool" features of
Python that always just makes people I talk to about Python go "wow!".
> > family, but that was rejected. The question is do we want to move towards
> > adding things like this, or should it stay relegated to places like the
> > Python Cookbook (which reminds me I should probably put this sucker up on
> > the site) and the Demo/ directory. Something to consider.
> I think that having everybody re-code the same powerful idioms all the time,
> when the idioms are well suited to being encapsulated in functions that the
> standard library might supply, is sub-optimal, even if the alternative is that
> the re-coding be mostly copying from the cookbook.
True. This does seem to go with the "batteries included" idea, although
at a more fundamental coding level.