RE: [Python-checkins] python/nondist/peps pep-0323.txt, NONE,
1.1 pep-0000.txt, 1.254, 1.255
python at rcn.com
Mon Oct 27 17:45:09 EST 2003
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,
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).
More information about the Python-Dev