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

Josiah Carlson jcarlson at uci.edu
Thu Dec 7 02:01:48 CET 2006

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

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.

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

More information about the Python-Dev mailing list