[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 01:01, Josiah Carlson wrote:
> > *We* may not be confused, but it's not about us (I'm personally  
> > happy to
> > use the .group() interface); it's about relative newbies who,  
> > generally
> > speaking, desire/need consistency (see [1] for a paper showing that
> > certain kinds of inconsistancies are bad  - at least in terms of  
> > grading
> > - for new computer science students). Being inconsistant because it's
> > *easy*, is what I consider silly. We've got the brains, we've got the
> > time, if we want slicing, lets produce a match object.
> 
> Oh, it isn't that I don't want to produce a match object; I think  
> you've mistaken my intention in that respect.  I'd be equally happy  
> for it to be a match object, *but*...
> 
> > 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.  In that
sense, buffer also doesn't support step != 1, but that's because it's
__getitem__ method doesn't accept slice objects, and uses the
(I believe deprecated or removed in Py3k) __getslice__ method.

We can easily check for such things in the __getitem__ method (to also
support the removal? of __getslice__) and raise an exception.  For those
who want reversed slices, they can use reversed(m[x:y]), etc.


> What led me to think that a tuple or list would be appropriate is the  
> idea that slicing was a useful operation and that I felt it was  
> unlikely that anyone would want to call the match object methods on a  
> slice, coupled with the fact that slices clearly have problems with  
> some of the match object methods.  A match object, plus sequence  
> functionality, minus match object methods, is basically just a sequence.

Explicit is better than implicit.  Refuse the temptation to guess.  Let
us give them the full match object.  If they want to do something silly
with slicing (reversed, skipping some, etc.), make them use list() or
islice().


> If you're worried about types, you could do something like this:
> 
>                generic match object
>                          |
>           +--------------+-------------+
>           |                            |
>    real match object            match object slice

I believe the above is unnecessary.  Slicing a match could produce
another match.  It's all internal data semantics.


 - Josiah