On Tuesday 28 October 2003 04:15 pm, Guido van Rossum wrote: ... > > > Every attempt should be made for the two copies to return exactly the > > > same stream of values. This is the pure tee() semantics. > > > > Yes, but iterators that run on underlying containers don't guarantee, > > in general, what happens if the container is mutated while the iteration > > is going on -- arbitrary items may end up being skipped, repeated, etc. > > So, "every attempt" is, I feel, too strong here. > > Maybe. > > I agree that for list and dict iterators, if the list is mutated, this > warrantee shall be void. OK, noticed -- and I'll clarify the PEP about this, thanks. > But I strongly believe that cloning a random iterator should cause two > identical streams of numbers, not two different random streams. If > you want two random streams you should create two independent > iterators. Most random number generators have a sufficiently small > amount of state that making a copy isn't a big deal. If it is hooked > up to an external source (e.g. /dev/random) then I'd say you'd have to > treat it as a file, and introduce explicit buffering. I really truly REALLY like this. I _was_ after all the one who lobbied Tim to add getstate and setstate to random.py, back in the not-so- long-ago time when I was a total Python newbie -- exactly because, being a NOT-newbie consumer of pseudo-random streams, I loathed and detested the pseudo-random generators that didn't allow me to reproduce experiments in this way. So, I entirely agree that if pseudo-random numbers are being consumed through a "pseudo-random iterator" the copy should indeed step through just the same numbers. Again, this will get in the PEP -- *thanks*! Btw, random.py doesn't seem to supply pseudo-random iterators -- easy to make e.g. with iter(random.random, None) [assuming you want a nonterminating one], but that wouldn't be copyable. Should something be done about that...? And as for NON-pseudo random numbers, such as those supplied by /dev/random and other external sources, yes, of course, they should NOT be copy'able -- best to let tee() work on them by making its buffer, or else wrap them in a buffer-to-file way if one needs to "snapshot" the sequence then re-"generate" a lot of it later for reproducibility purposes. I.e., absolute agreement. > > deepcopy exists for those cases where one is ready to pay a hefty > > price for guarantees of "decoupling", after all. > > But I don't propose that iterators support __deepcopy__. The use case > is very different. Yes, the use case of __deepcopy__ is indeed quite different (and to be honest it doesn't appear in my actual experience -- I can "imagine" some as well as the next man, but they'd be made out of whole cloth:-). But I was under the impression that you wanted them in PEP 323 too? Maybe I misunderstood your words. Should I take them out of PEP 323? In that case somebody else can later PEP that if they want, and I can basically wash my hands of them -- what do you think? 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