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

[Michael Urman]

On 12/6/06, Josiah Carlson <jcarlson at uci.edu> 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. If we don't want
> slicing, or if prodicing a slice would produce a semantically
> questionable state, then lets not do it.

The idea that slicing a match object should produce a match object
sounds like a foolish consistency to me. It's a useful invariant of
lists that slicing them returns lists. It's not a useful invariant of
sequences in general. This is similar to how it's a useful invariant
that indexing a string returns a string; indexing a list generally
does not return a list.

I only found a couple __getslice__ definitions in a quick perusal of
stdlib. ElementTree.py's _ElementInterface class returns a slice from
a contained list; whereas sre_parse.py's SubPattern returns another
SubPattern. UserList and UserString also define __getslice__ but I
don't consider them representative of the standards of non-string/list
classes.

As an aside, if you're trying to show that inconsistencies in a
language are bad by referencing a paper showing that people who used
consistent (if incorrect) mental models scored better than those who
did not, you may have to explain further; I don't see the connection.

-- 
Michael Urman  http://www.tortall.net/mu/blog