[Python-Dev] [NPERS] Re: a feature i'd like to see in python #2: indexing of match objects (original) (raw)

Josiah Carlson jcarlson at uci.edu
Thu Dec 7 22:47:41 CET 2006

Alastair Houghton <alastair at alastairs-place.net> wrote:

On 7 Dec 2006, at 02:01, Josiah Carlson wrote: > Alastair Houghton <alastair at alastairs-place.net> wrote: >> On 7 Dec 2006, at 01:01, Josiah Carlson wrote: >>> If we don't want >>> slicing, or if prodicing a slice would produce a semantically >>> questionable state, then lets not do it. >> >> ...if you return match objects from slicing, you have problems like m >> [::-1].groups(). I don't know what that should return. > > I would argue that any 'step' != 1 has no semantically correct result > for slicing on a match object, so we shouldn't support it.

OK, but even then, if you're returning a match object, how about the following: >>> m = re.match('(A)(B)(C)(D)(E)', 'ABCDE') >>> print m[0] ABCDE >>> n = m[2:5] >>> print list(n) ['B', 'C', 'D'] >>> print n[0] B >>> print n.group(0) B The problem I have with it is that it's violating the invariant that match objects should return the whole match in group(0).

If we were going to go with slicing, then it would be fairly trivial to include the whole match range. Some portion of the underlying structure knows where the start of group 2 is, and knows where the end of group 5 is, so we can slice or otherwise use that for subsequent sliced groups.

Interestingly, at present, the match object type itself is an implementation detail; e.g. for SRE, it's an sre.SREMatch object. It's only the API that's documented, not the type.

I believe that is the case with all built in cPython structures.

More information about the Python-Dev mailing list