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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
