[Python-Dev] Should we move to replace re with regex?

Steven D'Aprano steve at pearwood.info
Sat Aug 27 05:47:34 CEST 2011


Antoine Pitrou wrote:
> On Fri, 26 Aug 2011 17:25:56 -0700
> Dan Stromberg <drsalists at gmail.com> wrote:
[...]
>> If you add regex as "import regex", and the new regex module doesn't work
>> out, regex might be harder to get rid of.  from __future__ import is an
>> established way of trying something for a while to see if it's going to
>> work.
> 
> That's an interesting idea. This way, integrating the new module would
> be a less risky move, since if it gives us too many problems, we could
> back out our decision in the next feature release.

I'm not sure that's correct. If there are differences in either the 
interface or the behaviour between the new regex and re, then reverting 
will be a pain regardless of whether you have:

from __future__ import re
re.compile(...)

or

import regex
regex.compile(...)


Either way, if the new regex library goes away, code will break, and 
fixing it may not be easy. It's not likely to be so easy that merely 
deleting the "from __future__ ..." line will do it, but if it is that 
easy, then using "import re as regex" will be just as easy.

Have then been any __future__ features that were added provisionally? I 
can't think of any. That's not what __future__ is for, at least 
according to PEP 236.

http://www.python.org/dev/peps/pep-0236/

I can't think of any __future__ feature that could be easily reverted 
once people start relying on it. Either syntax would break, or behaviour 
would change.

The PEP even explicitly states that __future__ should not be used for 
changes which are backward compatible:

     Note that there is no need to involve the future_statement machinery
     in new features unless they can break existing code; fully backward-
     compatible additions can-- and should --be introduced without a
     corresponding future_statement.


I wasn't around for the move from 1.4 regex to 1.5 re, so I don't know 
what was done poorly last time. But I can't see why we should treat 
regular expressions so differently from (say) argparse and optparse.

from __future__ import optparse

No. Just... no.




-- 
Steven



More information about the Python-Dev mailing list