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

[Brett Cannon]

[Alex Martelli]

> On Sunday 24 November 2002 03:00 am, Brett Cannon wrote:
>    ...
> > #2 is the better option.  But it that complicated to write as a function::
> >
> > 	def peel(iterator, arg_cnt):
> > 		if not hasattr(iterator, 'next'):
> > 			iterator = iter(iterator)
> > 		for num in xrange(arg_cnt):
> > 			yield iterator.next()
> > 		else:
> > 			yield iterator
>
> I think this generator can be simplified without altering its behavior:
>
> def peel(iterator, arg_cnt=2):
>     iterator = iter(iterator)
>     for num in xrange(arg_cnt):
>         yield iterator.next()
>     yield iterator
>
> by exploiting the idempotence of iter on iterators and doing away with an
> unneeded else -- I also think defaulting arg_cnt to 2 is useful because I see
> myself using this most often for head/tail splits a la ML/Haskell, only
> occasionally for other purposes.  Admittedly, these are minor details.
>

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.

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.

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

Always learning something new.  =)

> I'm +0 on the ability to use "head, *tail = rhs" syntax as equivalent to
> "head, tail = peel(rhs)".  It's nice and it has an impressionistic analogy
> with positional-arguments passing, but not quite the same semantics
> as the latter (if tail is to be an iterator rather than a sequence), which
> makes it a little bit trickier to teach, and could be seen as a somewhat
> gratuitous syntax addition/extension for modest practical gain.  Much
> more might be gained by deciding on a small set of iterator-handling
> generators to go in a new standard library module -- right now every
> substantial user of generators is writing their own little helpers set.  But
> maybe waiting until more collective experience on what goes in such
> sets is accumulated is wiser.
>

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
iterators (although I have no clue what we would put in there).  Raymond
had his generator comprehensions with generator version of ``map()`` and
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.

-Brett