[Python-ideas] Experiment: Adding "re" to string objects.

Nick Coghlan ncoghlan at gmail.com
Sun Jul 19 22:02:33 CEST 2009

Antoine Pitrou wrote:
> Georg Brandl <g.brandl at ...> writes:
>> Nick Coghlan schrieb:
>>> However, the idea of adding more convenience classes to the re module
>>> may still have some merit. In particular, when checking against multiple
>>> regexes, being able to do something like the following might be helpful:
>>> m = re.Matcher(s)
>>> if m.match(r'whatever(.*)'):
>>>       print m.group(1)
>>> elif m.match(r'something (.*) else(.*)'):
>>>       print m.group(2)
> -0.5. Right now, objects in the re module are constructed from a regular
> expression pattern -- one of the reasons being that these patterns are compiled
> to bytecode form, and the objects help retain the bytecode. Having another
> object type constructed from the string-to-match is confusing. Besides, keeping
> some kind of internal state about the last matched pattern, only for
> "convenience" purposes, isn't pretty either.

As Georg pointed out, re.match() is still the number one use case that
gets brought up whenever people start talking about embedded assignment
 statements, and it is when matching against multiple patterns that the
problems hurts the most. The idea of a helper class in the re module to
simplify that idiom isn't a silly one, even if I would object
strenuously to the idea of building regex support directly into the
basic string types.

That said, I agree that my suggestion above is potentially confusing,
which is why I kicked this thread over here rather than continuing it on
python-dev. At the moment it is just a half-baked idea that occurred to
me when reading the python-dev thread - it would need somebody to pick
it up and iterate on the design a bit to come up with something
potentially worthy of inclusion in the re module.


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-ideas mailing list