New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RE parser too loose with {m,n} construct #41987
Comments
This seems wrong to me: >>> re.match("(UNIX{})", "UNIX{}").groups()
('UNIX',) With no numbers or commas, "{}" should not be considered |
Logged In: YES It's interesting what other RE implementations do with this Attached is a patch that fixes this behaviour in the |
Logged In: YES IMO, the simplest rule is that braces always be considered |
Logged In: YES So, should a {} raise an error, or warn like in Ruby? |
Logged In: YES I prefer Skip's third option, raising an exception during >>> a[]
SyntaxError: invalid syntax |
Logged In: YES Okay. Attaching patch which does that. BTW, these things are currently allowed too (treated as "{" The patch changes that, too. |
Logged In: YES In the absence of strong technical reasons, I'd vote to do what Perl |
Logged In: YES I just realized that e.g. the string module uses unescaped Perhaps the original patch (sre-brace-diff) is better... |
Logged In: YES Can you elaborate? I fail to see what the string module |
Logged In: YES Raymond said that braces should always be considered |
Logged In: YES Hmm, it looks like they cannot be treated differently |
Logged In: YES Then, I think, we should follow Perl's behaviour and treat |
Logged In: YES Any more objections against treating "{}" as literal? The impact on existing code will be minimal, as I presume no |
Logged In: YES I support Skip's opinion on following whatever perl is currently doing, if Your original patch looks under-optimal though (look at the tests around |
Logged In: YES No, you're the expert, so you'll get the honor of fixing it. :P |
Logged In: YES Fixed in: Lib/sre_parse.py: 1.64 -> 1.65 Notice that perl will also handle constructs like '{,2}' as |
Logged In: YES Will you backport the fix? |
Logged In: YES Was it a bug, or was it merely confusing semantics? |
Logged In: YES I would say bug. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: