[Python-Dev] Re: [ python-Bugs-416670 ] MatchObjects not deepcopy()able

[Martin v. Loewis]

> 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