[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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4