Le Mon, 15 Jul 2013 21:53:42 -0700, Guido van Rossum <gu...@python.org> a écrit : > Hm. I'd still like to change this, but I understand it's debatable... > Is the group() method written in C or Python?
Is there a strong enough use case to change it? I can't say the current behaviour seems very useful either, but some people may depend on it. I already find it a bit weird that you're passing a bytearray or memoryview to re.match(), to be honest :-) Regards Antoine. > 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 <ncogh...@gmail.com> > wrote: > > On 16 July 2013 12:20, Guido van Rossum <gu...@python.org> wrote: > >> On Mon, Jul 15, 2013 at 7:03 PM, Stephen J. Turnbull > >> <step...@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 | ncogh...@gmail.com | Brisbane, Australia > > > _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
