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

Brett Cannon bac@OCF.Berkeley.EDU
Sun, 24 Nov 2002 16:07:36 -0800 (PST)

[Alex Martelli]

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 numberofsplits or something like that would help the somewhat-careless reader;-).

=) This is what happens when you just code and post on a whim. =)

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

Oops. Rather cool, though, since that is a nice way to copy a list just like the [:] trick.

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

True, but there are possible things that are handy but you don't want to have as a full-blown method (and of course because I have said this no example is coming to my mind).

I guess I just have not come up with that many fancy tricks for iterators that would fill a module. The only other thing I have found handy is a wrapper function that keeps copies of what an iterator returns so you can index the result later; memoization for iterators.

There's no need to distinguish generators from other iterators in this respect; generators are just one neat implementation of iterators.

I totally agree with that assessment. Generators have always been a handy way of writing __iter__(). This is one of the "cool" features of Python that always just makes people I talk to about Python go "wow!".

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

True. This does seem to go with the "batteries included" idea, although at a more fundamental coding level.

-Brett