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

[Ben Wing]

Fredrik Lundh wrote:
> Martin v. Löwis wrote:
>
>   
>>> it can quickly become rather confusing if you also interpret m[:] as 
>>> m.groups(), not to mention if you add len() and arbitrary slicing to
>>> the mix.  what about m[] and m[i,j,k], btw?
>>>       
>> I take it that you are objecting to that feature, then?
>>     
>
> I haven't seen a complete and self-consistent proposal yet, so that's 
> not easy to say.
>
> </F>
>
>   
my current proposal can be summarized:

1. m[x] == m.group(x) for x an integer >= 0.
2. all other sequence properties should be consistent with this 
numbering and with the view of `m' as basically an array.
3. m[name] == m.group(name) for name a string; names are aliases for 
group numbers.

this implies, for example, that negative indices count from the end, 
that len(m) == 1 + m.lastindex, that the expression `m[1:]' should be 
the same as `m.groups()', that `foo in m' is true if `foo' is equal to 
any group in m or to the whole string, etc.  property 3 should also 
probably imply that names should be allowed as slice indices -- a name 
is just an alias for a group number, and should behave the same way.

an alternative would be to view a match object as a hash table.  then, 
slices would presumably be disallowed, and `foo in m' would be true if 
`foo' is a group number in range, or a name of a group.  but i don't 
like this as much; for example, it's not clear what len(m) should return 
in the case of a named group -- does it count the group once (since a 
name is just an alias), or twice?

(btw i never really thought until now about the inconsistency in the 
'in' operator between arrays and hash tables.)

ben