[Python-Dev] RE: [Python-checkins] python/nondist/peps
pep-0323.txt, NONE, 1.1 pep-0000.txt, 1.254, 1.255
Alex Martelli
aleaxit at yahoo.com
Tue Oct 28 11:35:41 EST 2003
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
More information about the Python-Dev
mailing list