Re: [Python-Dev] Re: syntactic shortcut - unpack to variably sizedlist
Raymond Hettinger wrote:
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 :) Cheers, Nick. <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@email.com | Mobile: +61 409 573 268
On Mon, 22 Nov 2004 20:36:11 +1000, Nick Coghlan <ncoghlan@iinet.net.au> wrote:
I also grew some doubts about iunpack(), as currently proposed. I still feel that it has enough of a use case to deserve discussion, but I'm not so sure about the details. I did check itertools before submitting my original implementation, and for some reason, I didn't perceive that islice coud be used for a similar effect with a slightly different usage pattern. One of the advantages of writing a PEP (or pre-PEP, as it is now) is that, even if not absolutely required for the proposed addition to itertools, it's still a way to encourage discussion and document the results. I also still think that the pre-PEP could be published on the main c.l.py list, for discussion and feedback. The key point is the comparison between iunpack and islice. If iunpack is deemed to be just an obvious extension to behavior that can already be achieved with iunpack, then fine -- forget it. The most that I can propose is to include an example in the documentation on how to achieve iunpack behavior with islice. On the other hand, if it becomes clear that the actual usage pattern for iunpack and islice are in fact different, then I would stand for the addition of iunpack. Of course, Raymond has the final word :-) -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: carribeiro@gmail.com mail: carribeiro@yahoo.com
On Mon, 22 Nov 2004 20:36:11 +1000, Nick Coghlan <ncoghlan@iinet.net.au> wrote:
I also grew some doubts about iunpack(), as currently proposed. I still feel that it has enough of a use case to deserve discussion, but I'm not so sure about the details. I did check itertools before submitting my original implementation, and for some reason, I didn't perceive that islice coud be used for a similar effect with a slightly different usage pattern. One of the advantages of writing a PEP (or pre-PEP, as it is now) is that, even if not absolutely required for the proposed addition to itertools, it's still a way to encourage discussion and document the results. I also still think that the pre-PEP could be published on the main c.l.py list, for discussion and feedback. The key point is the comparison between iunpack and islice. If iunpack is deemed to be just an obvious extension to behavior that can already be achieved with iunpack, then fine -- forget it. The most that I can propose is to include an example in the documentation on how to achieve iunpack behavior with islice. On the other hand, if it becomes clear that the actual usage pattern for iunpack and islice are in fact different, then I would stand for the addition of iunpack. Of course, Raymond has the final word :-) -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: carribeiro@gmail.com mail: carribeiro@yahoo.com
participants (2)
-
Carlos Ribeiro -
Nick Coghlan