Buggy or strange behaviour matching mutable data with `re`

[petersuttondev]

Bug report

Bug description:

import re
data = bytearray(b'1')
match = re.match(b'1', data)
print(match[0])  # b'1'
data[:] = b'2'
print(match[0])  # b'2'

If you match against mutable data (e.g., a bytearray) and change that data after matching, the matched values reported by the match change.

Is this a) a bug or b) strange behavior that should be pointed out in the docs (or c) none of the above)?

CPython versions tested on:

3.13

Operating systems tested on:

Linux

[ericvsmith]

I think it should be left alone and documented. The alternative of creating a copy would be a change I don't think we want to make: the inputs could be large. And for all we know, someone could be relying on this behavior.

[petersuttondev]

I agree. The only people matching against mutable data are doing so for performance or memory reasons (at least I was). So no point taking that away.

[picnixz]

I think it's half-expected. In match_getslice_by_index (which calls getstring/getslice) we don't make assumptions that the object we're matching against is a subclass of str or bytes, but either a str or any object implementing the buffer protocol.

@serhiy-storchaka was it expected to work like that or not? we already have guards against indices being out of ranges (I tried to trigger a UAF but we correctly export the buffer before using it with slices so we shouldn't have an issue here).