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

[Guido van Rossum]

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)