Raymond Hettinger wrote:
> Also, if the goal is just to get iunpack(), the good news is that PEP is
> not required. Only the a,b,*c syntax would need a PEP. The bad news is
> that I have the final say over what goes into itertools (I've rejected
> eight proposals so far, including one from Guido).
Actually, the goal (or my goal, anyway) was to avoid having the "a, b, *c = seq"
idea proposed again in a few months time. Google searches of the py-dev archive
can work sometimes, but a PEP is generally more visible.
However, if you follow through the rambling below, you'll find it doesn't leave
much for a PEP to say. . . so, unless Carlos or anyone else wants to run with
it, consider my PEPP from this thread to be dead :)
<Rambling summary of the discussion so far>
<I included it, since it is what lead me to the second paragraph above>
The basic idea of the "a, b, *c = seq" syntax is to unpack the first few items
of a sequence into specific variables, and then drop the rest of the sequence
into another variable (sometimes the original variable).
To me, the presented use cases are nowhere near significant enough to justify
special syntax. The other argument in favour (symmetry with extended function
call syntax) isn't compelling either, since function calls and assignment
statements are, well, different.
However, while I didn't find the use cases presented enough to justify a syntax
change, I wondered if they pointed towards some potentially missing features.
The current PEP draft grew out of the question "Is there a way to provide the
_functionality_ without altering Python's syntax?".
For objects that support slicing, the following works now:
a, b, the_rest = seq[:2] + [seq[2:]]
For iterators, roughly equivalent spelling is:
a, b, the_rest = [islice(itr, 2)] + [itr]
Carlos's suggestion gives a common way to spell it for any iterable:
a, b, the_rest = iunpack(iterable, 2)
Alternatively, if we stick with different spellings for mutable sequences and
iterators, we can get to:
a, b = seq.pop(slice(2))
a, b = islice(itr, 2)
In both of these cases, the original object (seq, itr) ends up containing "the
rest". Neither approach works for an immutable sequence, though - for those, it
is still necessary to use the explicit slicing spelling above (or create an
iterator and use the islice approach).
Anyway, if you're firmly opposed to itertools.iunpack, there isn't much point in
pursuing it (since, in the end, your opinion is the one that really counts).
Carlos may choose to post it as a recipe over at ASPN.
That still leaves adding slice handling to list.pop and array.pop. If nobody
else steps forward to do it, I expect I'll eventually get around to coming up
with a patch for that.
Nick Coghlan | Brisbane, Australia
Email: ncoghlan(a)email.com | Mobile: +61 409 573 268