[Python-Dev] Re: Reiterability
aleaxit at yahoo.com
Tue Oct 21 06:02:26 EDT 2003
On Tuesday 21 October 2003 05:44, Guido van Rossum wrote:
> All we care about really is that this is an instance with two instance
> variables, seq and i. A shallow copy creates a new instance (with a
> new __dict__!) with the same two instance variable names, referencing
> the same two objects. Since i is immutable, the copy/clone is
Ah -- *right*! The index can be taken as IMMUTABLE -- so the fact
that the copy is shallow, so gets "the same index object", is a red
herring -- as soon as either the copy or the original "increment" the
index, they're in fact creating a new index object for themselves while
still leaving their brother's index object unchanged. I get it now -- I
was thinking too abstractly and generally, in terms of a more general
"index" which might be mutable, thus shared (including its changes)
after a shallow copy.
> Now if someone wrote a tree class with a matching iterator class
> (which might keep a stack of nodes visited in a list), the default
> copy.copy() semantics might not be right, but such a class could
> easily provide a __copy__ method that did the right thing (making a
> shallow copy of the stack).
Yes, if we specify an iter's __copy__ makes an independent iterator,
which is surely the most useful semantics for it, then any weird iterator
whose index is in fact mutable can copy not-quite-shallowly and offer
the same useful semantics. I'm not sure where that leaves generator
made iterators, which don't really know which parts of the state in their
saved frame are "index", but having them just punt and refuse to copy
themselves shallowly might be ok.
> > > I see this as a plea to add __copy__ and __deepcopy__ methods to all
> > > standard iterators for which it makes sense. (Or maybe only __copy__
> > > -- I'm not sure what value __deepcopy__ would add.)
> > Hmmm, copy the underlying sequence as well? Don't have any use
> > case for it, but that's what would feel unsurprising to me (as I have
> > already mentioned I may not have the right mental model of an
> > iterator...).
> Right. I have no use case for this either, although it's close to
> pickling, and who knows if someday it might be useful to be able to
> pickle iterators along with their containers.
Sure, it might. Perhaps the typical use case would be one in which
an iterator gets deepcopied "incidentally" as part of the deepcopy of
some other object which "happens" to hold an iterator; if iterators knew
how to deepcopy themselves that would save some work on the part
of the other object's author. No huge win, sure. But once the copy
gets deep, generator-made iterators should also have no problem
actually doing it, and that may be another middle-size win.
> > > would be the road to supporting iterator cloning?
> > It would surely do a lot to let me clone things, yes, and in fact
> > doing it with the existing __copy__ protocol sounds much better
> > than sprouting a new one.
> Right, so that's settled. We don't need an iterator cloning protocol,
> we can just let iterators support __copy__. (There's no C-level slot
> for this.)
> > (Thanks for the confirmations and clarifications on file internals.
> > btw, any news of the new experimental file things you were
> > playing with back at PythonUK...?)
> No; I donated it to pypy and I think it's in their subversion depot.
> I haven't had time to play with it further. It would be great to do a
> rewrite from the ground up of the file object without using stdio, but
> it would be a lot of work to get it right on all platforms; I guess an
> engineering team of volunteers should be formed to tackle this issue.
Right, and doing so as part of pypy is surely right, since it's one of
the many things pypy definitely needs to become fully self-hosting.
More information about the Python-Dev