[Python-Dev] Misc re.match() complaint (original) (raw)

Guido van Rossum guido at python.org
Tue Jul 16 06:53:42 CEST 2013

Hm. I'd still like to change this, but I understand it's debatable... Is the group() method written in C or Python? If it's in C it should be simple enough to let it just do a little bit of pointer math and construct a bytes object from the given area of memory -- after all, it must have a pointer to that memory area in order to do the matching in the first place (although I realize the code may be separated by a gulf of abstraction :-).

--Guido

On Mon, Jul 15, 2013 at 8:03 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

On 16 July 2013 12:20, Guido van Rossum <guido at python.org> wrote:

On Mon, Jul 15, 2013 at 7:03 PM, Stephen J. Turnbull <stephen at xemacs.org> wrote:

Or is this something deeper, that a group is a new object in principle?

No, I just think of it as returning "a string" and I think it's most useful if that is always an immutable object, even if the target string is some other bytes buffer. FWIW, it feels as if the change in behavior is probably just due to how slices work. I took a look at the way the 2.7 re code works, and the change does indeed appear to be due to the difference in the way slices work for buffer and memoryview objects: Slicing a buffer creates an 8-bit string:

buffer(b"abc")[0:1] 'a' Slicing a memoryview creates another memoryview: memoryview(b"abc")[0:1] <memory at 0x7f3320541b98> Unfortunately, memoryview doesn't currently allow subclasses, so it isn't easy to create a derivative that coerces to bytes on slicing :( Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

-- --Guido van Rossum (python.org/~guido)

More information about the Python-Dev mailing list