On Mon, 22 Nov 2004 20:36:11 +1000, Nick Coghlan <ncoghlan at iinet.net.au> wrote: > 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. 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 at gmail.com mail: carribeiro at yahoo.com
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4