[Python-Dev] Half-baked proposal: * (and **?) in assignments
Sun, 24 Nov 2002 11:12:51 +0100
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;-).
> Didn't think (or realize) that raising an exception in the generator would
> kill the generator and not allow any more calls to ``.next()``. That was
> why I bothered with the ``else:`` statement.
Transparently propagating a StopIteration is often the nicest way to end a
generator, I think.
> 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...
> 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.
There's no need to distinguish generators from other iterators in this
respect; generators are just one neat implementation of iterators.
> 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.