Bugs item #1202493, was opened at 2005-05-15 16:59
Message generated for change (Comment added) made by montanaro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202493&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Regular Expressions
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: RE parser too loose with {m,n} construct
Initial Comment:
This seems wrong to me:
>>> re.match("(UNIX{})", "UNIX{}").groups()
('UNIX',)
With no numbers or commas, "{}" should not be considered
special in the pattern. The docs identify three numeric
repetition possibilities: {m}, {m,} and {m,n}. There's no
description of {} meaning anything. Either the docs should
say {} implies {1,1}, {} should have no special meaning, or
an exception should be raised during compilation of the
regular expression.
----------------------------------------------------------------------
>Comment By: Skip Montanaro (montanaro)
Date: 2005-06-03 10:13
Message:
Logged In: YES
user_id=44345
Can you elaborate? I fail to see what the string module
has to do with the re module. Can you give an example
of code that would break?
----------------------------------------------------------------------
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-03 03:01
Message:
Logged In: YES
user_id=1188172
I just realized that e.g. the string module uses unescaped
braces, so I think we should not become overly strict as it
would break much code...
Perhaps the original patch (sre-brace-diff) is better...
----------------------------------------------------------------------
Comment By: Skip Montanaro (montanaro)
Date: 2005-06-02 06:16
Message:
Logged In: YES
user_id=44345
In the absence of strong technical reasons, I'd vote to do what Perl
does. I believe the assumption all along has been that most people
coming to Python who already know how to use regular expressions are
Perl programmers. It wouldn't seem to make sense to throw little land
mines in their paths. I realize that explicit is better than implicit, but
practicality beats purity.
----------------------------------------------------------------------
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-01 16:32
Message:
Logged In: YES
user_id=1188172
Okay. Attaching patch which does that.
BTW, these things are currently allowed too (treated as
literals):
"{"
"{x"
"{x}"
"{x,y}"
"{1,x}"
etc.
The patch changes that, too.
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-01 16:07
Message:
Logged In: YES
user_id=80475
I prefer Skip's third option, raising an exception during
compilation. This is an re syntax error. Treat it the same
way that we handle similar situations with regular Python:
>>> a[]
SyntaxError: invalid syntax
----------------------------------------------------------------------
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-01 15:30
Message:
Logged In: YES
user_id=1188172
So, should a {} raise an error, or warn like in Ruby?
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-01 15:25
Message:
Logged In: YES
user_id=80475
IMO, the simplest rule is that braces always be considered
special. This accommodates future extensions, simplifies
the re compiler, and makes it easier to know what needs to
be escaped.
----------------------------------------------------------------------
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-01 11:54
Message:
Logged In: YES
user_id=1188172
It's interesting what other RE implementations do with this
ambiguity:
Perl treats {} as literal in REs, as Skip proposes.
Ruby does, too, but issues a warning about } being unescaped.
GNU (e)grep v2.5.1 allows a bare {} only if it is at the
start of a RE, but matches it literally then.
GNU sed v4.1.4 does never allow it.
GNU awk v3.1.4 is gracious and acts like Perl.
Attached is a patch that fixes this behaviour in the
appearing "common sense".
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202493&group_id=5470
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
