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

[Alastair Houghton]

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.

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.

If you're worried about types, you could do something like this:

               generic match object
                         |
          +--------------+-------------+
          |                            |
   real match object            match object slice

where the "generic match object" perhaps doesn't have all the methods  
that a "real match object" would have.  (In the extreme case, generic  
match object might basically just be a sequence type.)

Then slicing something that was a "generic match object" always gives  
you a "generic match object", but it might not support all the  
methods that the original match object supported.

> Half-assing it is a waste.

Sure.  We're agreed there :-)

>> Look, I give in.  There's no point trying to convince any of you
>> further, and I don't have the time or energy to press the point.
>> Implement it as you will.  If necessary it can be an extension of my
>> "re" replacement that slicing is supported on match objects.
>
> I'm sorry to see you give up so easily.  One thing to realize/remember
> is that basically everyone who frequents python-dev has their own  
> "make
> life easier" function/class library for those things that have been
> rejected for general inclusion in Python.

It's just that I'm tired and have lots of other things that need  
doing as well.  Maybe I do have a bit more time to talk about it,  
we'll see.

Kind regards,

Alastair.

--
http://alastairs-place.net