On Monday 27 October 2003 11:45 pm, Raymond Hettinger wrote: > 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). I will -- thanks! > 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). Yes, I'll have to mention that (that the royal road for user code to access "iterator copying" functionality is via tee() when feasible). > * 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. Heavy copies should be left to 'tee' more often than not. > * 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. Or saving to disk, beyond a further threshold. > Consider adding a section with pure python sample implementations for > listiter.__copy__, dictiter.__copy__, etc. OK, but some of it's gonna be very-pseudo code (how do you mimic dictiter's real behaviour in pure Python...?). > 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). I'll have to clarify this as for followup discussion on this thread -- pseudorandom iterators (I'll give an example) should be copyable and ensure the same stream from original and copy, real-random iterators (e.g. from /dev/random) not, iterators on e.g. lists and dicts should not freeze the underlying contained when copied any more than they do when first generated (in general if you mutate a dict or list you're iterating on, Python doesn't guarantee "sensible" behavior...). Thanks, Alex
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