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

[Josiah Carlson]

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.SRE_Match object.   
> It's only the API that's documented, not the type.

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


 - Josiah