On 02/23/2013 11:38 PM, Nick Coghlan wrote:
Status quo, 2 items (etc):
from itertools import islice iterargs = iter(args) command, subcommand = islice(iterargs, 2) # Grab the first two, leave the rest commands[command][subcommand](*iterargs) # Pass the rest to the subcommand
Or command, subcommand = next(iterargs), next(iterargs) or command = next(iterargs) subcommand = next(iterargs) These don't require the manual counting, nor do they feature the "discontinuity" you mentioned. FWIW I don't think this problem is bad enough, nor this idiom used frequently enough, to warrant new syntax. But I've been wrong before. I was musing on this topic and came up with what is probably a terrible alternate approach. What if there was some way for the RHS to know what the LHS was asking for in a destructuring assignment? Something like def __next_n__(self, n): "Returns a tuple of the next n items from this iterator." and if the object doesn't provide __next_n__ you fall back to the current explicit PyIter_Next() calls and failing if there aren't enough / there are too many. If we had this, we could make the second argument to islice() optional; it could infer how many items you wanted. (I don't think the "a, b, *c, d = rhs" form is relevant here as you'd always consume everything from rhs.) I'm not sure how bad an idea this is. But complicating the iterator protocol for this marginal problem seems like a pretty bad idea. //arry/