Carlos Ribeiro wrote: > I may be wrong (and if that's the case, I would like to be politely > educated on why), but isn't it already on a PEP-worthy point? IOW, if > people are not interested, then the PEP will simply be rejected, which > is a good thing, because it will at least document the case. Good point - I've sent it to the PEP editors to request a number. > I also > believe that the pre-PEP should be posted to the main Python list, > where it may be beaten to death & flamed by a larger audience. I am > willing to do it myself, but I assume that is more polite on my part > if I ask you to do it :-) I'd wait to see what the PEP editors think, myself. I'm not entirely sure the idea is focused well enough to make a good PEP (I could argue either way, and I wrote the thing!). However, if you want to post it over there for discussion, feel free. >>Reference Implementation >>======================== >> >>As yet, no reference implementation is available for either part of the proposal. > > > I though the iunpack() code in the previous section would be > acceptable as a 'reference implementation'. Unfortunately, itertools is a C module :P >>Open Issues >>=========== >> >>- Should ``itertools.iunpack`` call ``iter()`` on its first argument? > > +1 We'll go with that then. . . y'know, I could have made that change before sending the PEP draft in. Ah well, we can change it later - I doubt the PEP will surive c.l.p. (or even py-dev) unscathed, anyway. Cheers, Nick. -- Nick Coghlan | Brisbane, Australia Email: ncoghlan at email.com | Mobile: +61 409 573 268
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