[Python-Dev] New regex module for 3.2?

Vlastimil Brom vlastimil.brom at gmail.com
Tue Jul 13 13:39:45 CEST 2010

2010/7/8 MRAB <python at mrabarnett.plus.com>:
> Hi all,
> I re-implemented the re module, adding new features and speed
> improvements. It's available at:
>    http://pypi.python.org/pypi/regex
> under the name "regex" so that it can be tried alongside "re".
> I'd be interested in any comments or feedback. How does it compare with
> "re" in terms of speed on real-world data? The benchmarks suggest it
> should be faster, or at worst comparable.
> How much interest would there be in putting it in Python 3.2?

please, let me apologize for posting here, not being a python developer;
I'd like to support the inclusion of the new regex library in the standard lib.
I use it since the early development versions in my internal app for
searching, modifying, ordering, extracting data from text - mainly
using the manually created regex patterns. I see, that it is only one
specific usecase, and the app isn't  time or space critical (input
texts up to a few MB, mostly smaller; the processing time is often
rather negligible compared to the gui presentation, styling etc.)
However, I see it as a great enhancement both in terms of regex
features (listed on http://pypi.python.org/pypi/regex ) as well as the
behaviour in some cornercases, which aren't effectively usable in the
current re (e.g. nested subexpressions with quantifiers - while many
of these are more effectively solved with the added possesive
I think, this is a far more feature complete engine, which doesn't
induce any significant drawbacks (IMO) comparing to the current re and
is backward compatible.
(The mentioned exception in the scoped flags might be fixable by
allowing only explicit scoping (?flags)...(?-flags) or using the
current paren, if possible (?flag:...) and treating the bare flag
setting parens as global;
however, I would consider it quite misleading in the current re, if
these flags are set at some other place than at the beginning of the
pattern. I don't see the readability enhanced in any way with these
flags set at the end, while they should apply from the beginning of
the pattern.)

Having seen MRABs commitment in the development phase in both -
bugfixes and feature additions - including some rather complex ones
(in my opinion) like unicode properties, I am also confident, that he
could be a competent maintainer of this package in the standardlib as

just my biased opinion...

   Vlastimil Brom

More information about the Python-Dev mailing list