Repository navigation
re incompatibility in sre #33084
Description
| BPO | 214033 |
|---|---|
| Nosy | @gvanrossum, @loewis, @birkenfeld, @devdanzin |
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:
assignee = None
closed_at = <Date 2009-02-12.19:32:42.344>
created_at = <Date 2000-09-11.08:24:15.000>
labels = ['expert-regex', 'type-bug']
title = 're incompatibility in sre'
updated_at = <Date 2009-02-12.19:32:42.342>
user = 'https://github.com/loewis'bugs.python.org fields:
activity = <Date 2009-02-12.19:32:42.342>
actor = 'ajaksu2'
assignee = 'effbot'
closed = True
closed_date = <Date 2009-02-12.19:32:42.344>
closer = 'ajaksu2'
components = ['Regular Expressions']
creation = <Date 2000-09-11.08:24:15.000>
creator = 'loewis'
dependencies = []
files = []
hgrepos = []
issue_num = 214033
keywords = []
message_count = 8.0
messages = ['1325', '1326', '1327', '1328', '1329', '1330', '74683', '81807']
nosy_count = 7.0
nosy_names = ['gvanrossum', 'loewis', 'effbot', 'tmick', 'georg.brandl', 'ajaksu2', 'timehorse']
pr_nums = []
priority = 'normal'
resolution = 'out of date'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue214033'
versions = ['Python 2.6']
Activity
loewis commentedon Sep 11, 2000
[submitted by Adam Sampson]
Under Python 1.5.2, I had a script containing the following line:
Under 1.6, this fails with:
[...]
File "/usr/local/lib/python1.6/sre.py", line 44, in match
return _compile(pattern, flags).match(string)
File "/usr/local/lib/python1.6/sre.py", line 102, in _compile
raise error, v # invalid expression
sre_constants.error: nothing to repeat
I can narrow it down to:
whereas:
works fine. Is this correct behaviour for SRE, or am I just being stupid?
"(x?)?" looks like a perfectly reasonable Perl-style regexp to me (and Perl
too)...
gvanrossum commentedon Oct 1, 2000
Martin, is this still broken in 2.0? Fredrik, any idea?
loewis commentedon Oct 1, 2000
Yes, it is still broken in 2.0b2.
tmick commentedon Apr 10, 2006
Logged In: YES
user_id=34892
I've run into another incarnation of this (it breaks in
Python 2.3.5 and Python 2.4.3):
>>> import sre >>> sre.compile("(a*)?") Traceback (most recent call last): File "<stdin>", line 1, in ? File "C:\Python24\Lib\sre.py", line 180, in compile return _compile(pattern, flags) File "C:\Python24\Lib\sre.py", line 227, in _compile raise error, v # invalid expression sre_constants.error: nothing to repeatNow granted that the '?' here is redundant for the '*'
quantifier on 'a', but compiling this regex works with
Python 2.3's "pre" and it works in Perl.
The actual use case I've hit here is trying to compile all
the regex's in Fedora Core 5's SELinux config files
(/etc/selinux/targeted/contexts/files/file_contexts*). The
first such regex that broke was:
'/usr/share/selinux-policy([^/]*)?/html(/.*)?'
birkenfeld commentedon Jun 1, 2006
Logged In: YES
user_id=849994
bpo-1456280 is a duplicate of this.
collinwinter commentedon Mar 21, 2007
The original bug no longer applies to Python 2.5.0 or 2.6a0. Trent's bug still exists in Python 2.5.0 and 2.6a0 (where 2.6a0 == SVN r54478).
timehorse commentedon Oct 13, 2008
The duplicate zero-or-one repeat operator bug described in this issue
originally no longer exists in python 2.6.
However, Trent Mick brings up a fair point in that expressions of the
form (x*)? generate an error (bpo-1456280) when internally the '?'
should be passively stripped from the expression by the Python Regular
Expression Compiler because it is redundant. The same goes for
expressions of the form (x*)* (bpo-2537). Also, there is a problem
with expressions of the form (x*){n,m} (bpo-1633953), since the x*
matches as much as it can, and thus it sees the range repeat operation
as redundant -- in this case I think the range repeat should have the
effect of matching (x*)(x*)(x*)... n to m times, but since the first
time matches everything, the subsequent matches all match zero-width
expressions following the first one. I am tracking all of these issues
under Item 33 of bpo-2636.
The are the 3 known redundant repeat issues, but this one, the zero-or-
one followed by zero-or-one is AFAICT fixed in python 2.6 as the
expression originally listed now passes compile.
devdanzin commentedon Feb 12, 2009
Jeffrey, Collin, thanks for reviewing.