Excellent PEP! Consider adding your bookmarking example. I found it to be a compelling use case. Also note that there are many variations of the bookmarking theme (undo utilities, macro recording, parser lookahead functions, backtracking, etc). Under drawbacks and issues there are a couple of thoughts: * Not all iterators will be copyable. Knowing which is which creates a bit of a usability issue (i.e. the question of whether a particular iterator is copyable will come up every time) and a substitution issue (i.e. code which depends on copyability precludea substitution of other iterators that don't have copyability). * In addition to knowing whether a given iterator is copyable, a user should also know whether the copy is lightweight (just an index or some such) or heavy (storing all of the data for future use). They should know whether it is active (intercepting every call to iter()) or inert. * For heavy copies, there is a performance trap when the stored data stream gets too long. At some point, just using list() would be better. Consider adding a section with pure python sample implementations for listiter.__copy__, dictiter.__copy__, etc. Also, I have a question about the semantic specification of what a copy is supposed to do. Does it guarantee that the same data stream will be reproduced? For instance, would a generator of random words expect its copy to generate the same word sequence. Or, would a copy of a dictionary iterator change its output if the underlying dictionary got updated (i.e. should the dict be frozen to changes when a copy exists or should it mutate). Raymond Hettinger
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