Re: [ python-Bugs-416670 ] MatchObjects not deepcopy()able
In the re-Module which come with Python version 2.0 (Nov 28 11:10 re.py) the created MatchObjects cannot be copied with a deepcopy(). Switching back to the old "pre.py" as proposed in "re.py" makes everything work ok.
thought I'd check this one with python-dev before marking it as "won't fix". I cannot see any reason why anyone would even attempt to deepcopy match objects... (cannot see any reason why anyone would use deepcopy for anything, but that's another story) Cheers /F
[/F]
thought I'd check this one with python-dev before marking it as "won't fix". I cannot see any reason why anyone would even attempt to deepcopy match objects...
Likely just because they're part of other objects, like bound to instance attributes, or members of lists. No matter how deep they're buried, someone trying to deepcopy a container will eventually need to deepcopy them too.
(cannot see any reason why anyone would use deepcopy for anything, but that's another story)
It's a std way to get a clone of an object, and when you don't want mutations of the clone to have any effect on the original (or vice versa). Perhaps if I call it the Clone Pattern, people will assume that makes it a good thing and cut that part of the debate mercifully short <wink>. It's *nice* to supply a deepcopy operation whenever it's doable with reasonable effort. I agree you're not required to in this case -- but it would still be "nice", if that's feasible.
tim wrote:
It's a std way to get a clone of an object, and when you don't want mutations of the clone to have any effect on the original (or vice versa). Perhaps if I call it the Clone Pattern, people will assume that makes it a good thing and cut that part of the debate mercifully short <wink>.
which leads to a followup question: the current approach seems to be to hack the copy.py file for each and every type. imo, that's rather unpythonic, and also introduces lots of unnecessary module dependencies. time to add a __clone__ slot? or could someone who knows what he's doing here address this comment in copy.py: # XXX need to support copy_reg here too... Cheers /F
Fredrik Lundh wrote:
tim wrote:
It's a std way to get a clone of an object, and when you don't want mutations of the clone to have any effect on the original (or vice versa). Perhaps if I call it the Clone Pattern, people will assume that makes it a good thing and cut that part of the debate mercifully short <wink>.
which leads to a followup question: the current approach seems to be to hack the copy.py file for each and every type. imo, that's rather unpythonic, and also introduces lots of unnecessary module dependencies.
time to add a __clone__ slot?
or could someone who knows what he's doing here address this comment in copy.py:
# XXX need to support copy_reg here too...
All you have to do is implement the copy protocol (ie. .copy()) for the type/class in question. -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/
mal wrote:
time to add a __clone__ slot?
or could someone who knows what he's doing here address this comment in copy.py:
# XXX need to support copy_reg here too...
All you have to do is implement the copy protocol (ie. .copy()) for the type/class in question.
cannot find any support for that in the copy module (not in 2.0, at least) but another reading revealed support for __copy__ and __deepcopy__ methods in at least 1.5.2 and later. intriguing... Cheers /F
Fredrik Lundh wrote:
mal wrote:
time to add a __clone__ slot?
or could someone who knows what he's doing here address this comment in copy.py:
# XXX need to support copy_reg here too...
All you have to do is implement the copy protocol (ie. .copy()) for the type/class in question.
cannot find any support for that in the copy module (not in 2.0, at least)
but another reading revealed support for __copy__ and __deepcopy__ methods in at least 1.5.2 and later. intriguing...
You're right... the two methods are named __copy__ and __deepcopy__. Both should return either copies of the object or simply new reference in case the object's are immutable. I've implemented these in mxDateTime and that was all it took to get the copy module happy (at least in Python 1.5.2). -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/
On Fri, 27 Apr 2001, "Fredrik Lundh" <fredrik@pythonware.com> wrote:
time to add a __clone__ slot?
It's called __setstate__ and __getstate__, I think? Don't these have an appropriate C-level slots?
# XXX need to support copy_reg here too...
I think it's talking about having copy be the same (but without the middle man) as Unpickle.loads(Pickle.dumps(o)) (which is a perfect copy.deepcopy, if a bit wasteful. -- "I'll be ex-DPL soon anyway so I'm |LUKE: Is Perl better than Python? looking for someplace else to grab power."|YODA: No...no... no. Quicker, -- Wichert Akkerman (on debian-private)| easier, more seductive. For public key, finger moshez@debian.org |http://www.{python,debian,gnu}.org
[Fredrik Lundh]
which leads to a followup question: the current approach seems to be to hack the copy.py file for each and every type. imo, that's rather unpythonic, and also introduces lots of unnecessary module dependencies.
time to add a __clone__ slot?
Note that classes can supply custom cloners via defining __copy__ and __deepcopy__ methods, without changing copy.py. A __clone__ slot for *types* would need to address the shallow vs deep question too, along with the other __getinitargs__, __getstate__, __setstate__ gimmicks. How many slots does that add up to? I leave it to the PEP author to count them <wink>. The copy.py protocols kinda grew up with pickle.py's, and together still have the flavor (to my tongue) of a prototype caught late in midstream. That is, it feels like they're not quite finished yet.
or could someone who knows what he's doing here address this comment in copy.py:
# XXX need to support copy_reg here too...
copy_reg is one of the pickle.py facilities that copy.py "should use" too; it's a registration database that tells pickle what to do about objects of types pickle doesn't understand directly (so *could* also be directly relevant to cloning objects of types copy.py doesn't understand directly -- depending).
[Sorry, this bounced -- my new work mail isn't set up right yet]
In the re-Module which come with Python version 2.0 (Nov 28 11:10 re.py) the created MatchObjects cannot be copied with a deepcopy(). Switching back to the old "pre.py" as proposed in "re.py" makes everything work ok.
thought I'd check this one with python-dev before marking it as "won't fix". I cannot see any reason why anyone would even attempt to deepcopy match objects...
(cannot see any reason why anyone would use deepcopy for anything, but that's another story)
Why don't you ask what they were doing? They cared enough to figure a workaround *and* report a bug. I think they deserve a better answer than Won't Fix. --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (6)
-
Fredrik Lundh
-
Fredrik Lundh
-
Guido van Rossum
-
M.-A. Lemburg
-
Moshe Zadka
-
Tim Peters