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

Alex Martelli aleax@aleax.it
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 argcnt 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.

Alex