[Python-Dev] sysconfig/SRE bug

[Fredrik Lundh]

andrew wrote:


> sysconfig.py contains a pattern that breaks SRE:
>=20
> >>> import re, pre
> >>> pre.compile(r"\${([A-Za-z][A-Za-z0-9_]*)}")
> <pre.RegexObject instance at 0x827a394>
> >>> re.compile(r"\${([A-Za-z][A-Za-z0-9_]*)}")
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "/usr/lib/python2.0/sre.py", line 54, in compile
>     return _compile(pattern, flags)
>    ...
>   File "/usr/lib/python2.0/sre_parse.py", line 538, in parse
>     p =3D _parse(source, state)
>   File "/usr/lib/python2.0/sre_parse.py", line 394, in _parse
>     raise error, "bogus range"
>=20
> Escaping the { and } fix this.  This is a problem with the {xxx,yyy}
> notation for ranges; PCRE looks ahead, and treats it as a literal
> unless it's followed by digits of the right form.  From pypcre.c:
>=20
> /* This function is called when a '{' is encountered in a place where =
it might
> start a quantifier. It looks ahead to see if it really is a quantifier =
or not.
> It is only a quantifier if it is one of the forms {ddd} {ddd,} or =
{ddd,ddd}
> where the ddds are digits.
> */
>=20
> I suppose the goal of Perl compatibility means this magical behaviour
> needs to be preserved?

I'm not so sure about this one; the $ behaviour is documented
in Perl, but this isn't (as far as I can tell, at least).  and since
it's detected by the parser, it's probably better to change the
sysconfig module...

(fixing this in the sre_parser isn't exactly trivial, either...)

</F>