A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2003-October/039702.html below:

[Python-Dev] RE: cloning iterators again

[Python-Dev] RE: cloning iterators againGuido van Rossum guido at python.org
Tue Oct 28 10:33:34 EST 2003
I've lost context for the following thread.  What is this about?  I
can answer one technical question regardless, but I have no idea what
I'm promoting here. :-)

> Hello Alex,
> 
> On Mon, Oct 27, 2003 at 04:09:03PM +0100, Alex Martelli wrote:
> > Cool!  Why don't you try copy.copy on types you don't automatically
> > recognize and know how to deal with, BTW?  That might make this
> > cool piece of code general enough that Guido might perhaps allow
> > generator-produced iterators to grow it as their __copy__ method...
> 
> I will try.  Note that only __deepcopy__ makes sense, as far as I can tell,
> because there is too much state that really needs to be copied and not shared
> in a generator (in particular, the sequence iterators from 'for' loops).
> 
> I'm not sure about how deep-copying should be defined for built-in
> types.  Should a built-in __deepcopy__ method try to import and call
> copy.deepcopy() on the sub-items? This doesn't seem to be right.

Almost -- you have to pass the memo argument that your __deepcopy__
received as the second argument to the recursive deepcopy() calls, to
avoid looping on cycles.

> A bientot,
> 
> Armin.

--Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list

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