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

Brett Cannon bac@OCF.Berkeley.EDU
Sun, 24 Nov 2002 01:34:08 -0800 (PST)

[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, argcnt): > if not hasattr(iterator, 'next'): > iterator = iter(iterator) > for num in xrange(argcnt): > yield iterator.next() > else: > yield iterator

I think this generator can be simplified without altering its behavior: def peel(iterator, argcnt=2): iterator = iter(iterator) for num in xrange(argcnt): yield iterator.next() yield iterator by exploiting the idempotence of iter on iterators and doing away with an unneeded else -- I also think defaulting argcnt 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