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>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4