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.