[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 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.

We'll have to agree to disagree.


> >> 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.

In Python 2.5:

>>> a
<_sre.SRE_Match object at 0x008F6020>
>>> dir(a)
['__copy__', '__deepcopy__', 'end', 'expand', 'group', 'groupdict',
'groups', 'span', 'start']

Not including end, expand, group, groupdict, groups, span, and start
may be confusing to some number of users.  Why?  Because of the
historical invariant already present in the standard library (with the
exception of buffer, I was wrong about that one).

*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. If we don't want
slicing, or if prodicing a slice would produce a semantically
questionable state, then lets not do it.

I honestly don't care about whether slicing should go in or not, I use
(?=) when I don't want a group.  What I really don't want is someone
coming in days after 2.6 is released complaining about match slicing not
supporting things they think they need.  Better to just tell them: use
list(m)[x:y] or islice(iterable, [start,] stop [, step]) (both of which
should work on arbitrary iterables, the latter of which works on
*infinite* iterables) or produce a match object.  All or nothing. 
Half-assing it is a waste.


> 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.


 - Josiah

[1] http://www.cs.mdx.ac.uk/research/PhDArea/saeed/paper1.pdf