[ python-Bugs-416670 ] MatchObjects not deepcopy()able
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...
What's wrong with patch #419070, which fixes the bug? Like any other immutable object, deepcopying a match object means returning it. Regards, Martin
Martin v. Loewis wrote:
What's wrong with patch #419070, which fixes the bug? Like any other immutable object, deepcopying a match object means returning it.
what makes you think a match object is immutable? import array, sre a = array.array("c", "abcde") m = sre.search("bcd", a) print m.group(0) Cheers /F
what makes you think a match object is immutable?
Because you cannot modify their state.
import array, sre
a = array.array("c", "abcde") m = sre.search("bcd", a) print m.group(0)
a1 = m.group(0) a1[0]='z' print m.group(0) So you'd have to modify a, to modify m.group(0). To catch this case, you might want to do def copy_match(m): g = m.group(0) if copy(g) is not g: raise KeyError # will be re-raised as copy.Error return g That will restore backwards compatibility with pre, which is what the submitter of the bug requested. Regards, Martin
Martin v. Loewis wrote:
Because you cannot modify their state.
same thing as tuples: you cannot modify the tuples, but you can modify their members. as its name implies, deepcopy can deal with tuples...
So you'd have to modify a, to modify m.group(0). To catch this case, you might want to do
def copy_match(m): g = m.group(0) if copy(g) is not g: raise KeyError # will be re-raised as copy.Error return g
That will restore backwards compatibility with pre, which is what the submitter of the bug requested.
which means that deepcopy sometimes work on match objects, and sometimes doesn't. *that* sounds like a bug to me. frankly, I don't think the original problem is a bug at all -- I think someone's abusing a CPython 1.5.2 implementation detail. it's not documented to work, it's not in the test suite, and it's not exactly the only thing in there that cannot be deepcopied... introducing broken behaviour to deal with someone's broken program sounds like a rather lousy idea -- and a dangerous precedent. user code shouldn't depend on accidental implementation details. Cheers /F
which means that deepcopy sometimes work on match objects, and sometimes doesn't. *that* sounds like a bug to me.
So I'll provide documentation; that will make it a feature. arrays cannot be copied either - for no good reason, AFAICT. Given that they cannot be copied, it is not surprising that match objects referring to array objects cannot be deepcopied. The "sometimes works, sometimes doesn't" aspect of deepcopy holds for any container object: class X:pass x = X() x.values = [1,2,3] y = copy.deepcopy(x) # succeeds x1 = X() x1.values = array.array("i",[1,2,3]) y1 = copy.deepcopy(x1) # fails
frankly, I don't think the original problem is a bug at all -- I think someone's abusing a CPython 1.5.2 implementation detail.
It is not abuse. There was no indication in the documentation that there might be a problem. He probably has a match object as an instance attribute, and wants to copy the instance. He does not care whether the match object is shared across copies. He only wants the instance copying to succeed - which it does in Python 1.5, whereas it fails in 2.0.
it's not documented to work, it's not in the test suite, and it's not exactly the only thing in there that cannot be deepcopied...
The documentation says # This version does not copy types like module, class, function, # method, stack trace, stack frame, file, socket, window, array, or # any similar types. So is a match object of "any similar type" or not? Next time, somebody breaks copying tuples, and claims that tuples are certainly similar to arrays... There is no indication whatsoever that copying match objects is not supported - even though the documentation does give a list of types that are not supported.
introducing broken behaviour to deal with someone's broken program sounds like a rather lousy idea -- and a dangerous precedent. user code shouldn't depend on accidental implementation details.
As I said: the user reading the 1.5 documentation had no way to tell that it was an "accidental implementation detail". The user reading the 2.0 documentation had no way to tell that this detail had been changed. So there clearly is a bug here. If you want to reject my patch, fine. But at a minimum, there should be documentation changes to deal with the problem. Regards, Martin
participants (2)
-
Fredrik Lundh
-
Martin v. Loewis