[snip]
> 13) Implement a grouptuples(...) method as per Mark Summerfield's
> suggest on 2008-05-28 09:38.  grouptuples would take the same filtering
> parameters as the other group* functions, and would return a list of 3-
> tuples (unless only 1 group was requested).  It should default to all
> match groups (1..n, not group 0, the matching string).

:-)

[snip]
> Finally, I would like suggestions on how to handle name collisions when
> match group names are provided as attributes.  For instance, an
> expression like '(?P<pos>.*)' would match more or less any string and
> assign it to the name "pos".  But "pos" is already an attribute of the
> Match object, and therefore pos cannot be exposed as a named match group
> attribute, since match.pos will return the usual meaning of pos for a
> match object, not the value of the capture group names "pos".
>
> I have 3 proposals as to how to handle this:
>
> a) Simply disallow the exposure of match group name attributes if the
> names collide with an existing member of the basic Match Object
> interface.

I don't like the prefix ideas and now that you've spelt it out I don't
like the sometimes m.foo will work and sometimes it won't. So I prefer
m['foo'] to be the canonical way because that guarantees your code is
always consistent.

------------------------------------------------------------
BTW I wanted to do a simple regex to match a string that might or might
not be quoted, and that could contain quotes (but not those used to
delimit it). My first attempt was illegal:

    (?P<quote>['"])?([^(?=quote)])+(?(quote)(?=quote))

It isn't hard to work round but it did highlight the fact that you can't
use captures inside character classes. I don't know if Perl allows this;
I guess if it doesn't then Python shouldn't either since GvR wants the
engine to be Perl compatible.