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

[Alastair Houghton]

On 6 Dec 2006, at 20:29, Josiah Carlson wrote:

> The problem is that either we return a list (easy), or we return
> something that is basically another match object (not quite so easy).
> Either way, we would be confusing one set of users or another.  By not
> including slicing functionality by default, we sidestep the confusion.

But I don't believe that *anyone* will find it confusing that it  
returns a list.

It's much more likely to be confusing to people that they have to write

   list(m)[x:y]

or

   [m[i] for i in xrange(x,y)]

when m[x] and m[y] work just fine.

>> As someone who is primarily a *user* of Python, I prefer the idea
>> that sequence objects should operate consistently to the idea that
>> there might be some that don't.  By which I mean that anything that
>> supports indexing using integer values should ideally support slicing
>> (including things like [::-1]).
>
> You are being inconsistant.  You want list, tuple, etc. to be  
> consistant,
> but you don't want match objects to be consistant.  Sorry, but that is
> silly. Better to not support slices than to confuse the hell out of
> people by returning a tuple or list from a match slicing.

That's not true *and* I object to your characterisation of the idea  
as "silly".  What I'm saying is that the idea of slicing always  
returning the same exact type of object is pointless consistency,  
because nobody will care *provided* the thing that is returned  
supports a sensible set of operations given the original type.

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.

Kind regards,

Alastair.

--
http://alastairs-place.net