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

[Brett Cannon]

[Alex Martelli]

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

-Brett