Python thing that doesn't work in Sage, works in pure Python

edit

For others that stumble across this question, you can turn the Sage preparser off by calling preparser(False). Then the code above works just fine at the Sage command line:

sage: preparser(False)
sage: import re
sage: ST = "foobarsws"
sage: matches = re.match("(?:foo)?(bar)?(sws)?",ST)
sage: matches.groups()
('bar', 'sws')
sage: matches.group()
'foobarsws'
sage: matches.group(0)
'foobarsws'
sage: matches.group(1)
'bar'

To some extent, this might be a flaw in python's interface. There's an ambiguity to what matches.group is supposed to do:

matches.group(i)

should have the same effect as

matches.groups()[i]

or as

matches.groupdict()[i]

depending on the nature of i. As it happens, the C code decides on whether i passes PyInt_Check (i.e., really is an integer), so if i is Integer(1) then i is interpreted as a key into explicitly named groups. Unfortunately, the rules are a little strict for what the names of named groups can be, so if i is an Integer, it will never be valid as such:

sage: matches = re.match("(?:foo)(?P<1>bar)(?P<2>sws)?",ST)
error: bad character in group name

It's documented that group names must follow the same rules as valid python identifiers. Valid use is:

sage: matches = re.match("(?:foo)(?P<a>bar)(?P<b>sws)?",ST)
sage: matches.group('a')
'bar'

so the problem is a muddled interface: matches.group(i) must choose whether to try to interpret i as an integer or as a string. There is of course no good answer if i is neither and indeed, the code hardly tries anything.

In the last example, matches.group(i) should work for any i that compares equal to a or b and hashes consistently with that.