Repository navigation
re.sub confusion between count and flags args #56166
Description
Activity
re.sub don't substitute not ASCII characters:
Python 2.7.1 (r271:86832, Apr 15 2011, 12:11:58) Arch Linux
>>import re
>>a=u'aaa'
>>print re.search('(\w+)',a,re.U).groups()
(u'aaa')
>>print re.sub('(\w+)','x',a,re.U)
xBUT:>>a=u'ąąą'
>>print re.search('(\w+)',a,re.U).groups()
(u'\u0105\u0105\u0105')
>>print re.sub('(\w+)','x',a,re.U)
ąąąThe 4th parameter to re.sub() is a count, not flags.
Reacted by arsen671games3Since this has been reported already several times (see e.g. bpo-11947), and it's a fairly common mistake, I think we should do something to avoid it.
A few possibilities are:
- add a warning in the doc;
- make count and flag keyword-only argument (raising a deprecation warning in 3.3 and actually change it later);
- change the regex flags to some object that can be distinguished from ints and raise an error when a flag is passed to count;
- changed the title
[-]re.sub problem with unicode string[/-][+]re.sub confusion between count and flags args[/+]on Apr 30, 2011 I like the idea of an internal REflag class with __new__, __or__, and __repr__==str. Str(re.A|re.L) might print as
"REflag: re.ASCII | re.IGNORE"
If it is *not* an int subclass, any attempt to use or mix with an int would raise. I checked and the doc only promises that flags can be or'ed. An __and__ method might be added if it were thought that people currently use & to check for flags set, though that is not currently promised.Something like "<re.Flag ASCII | IGNORE>" may be more Pythonic.
Agreed, if we go that route.
I’d favor 1) or 2) over 3). Ints are short and very commonly used for flags.
See also bpo-12888 for an error in the stdlib caused by this.
- addedtype-featureA feature request or enhancementA feature request or enhancement
on Apr 10, 2013 I like option #2, and I was thinking of working on it today, poke me if anyone has a problem with this.
There is no sane way to issue a warning without changing the signature and we don't want to change the signature without issuing a deprecation warning for the function, so sadly option 3 is the only way for this to work, (Im going to not touch this till ENUMS are merged in.)
29 remaining items
- added a commit that references this issue
on Sep 27, 2024 - added a commit that references this issue
on Sep 30, 2024 - added a commit that references this issue
on Oct 25, 2024 - added a commit that references this issue
on Nov 13, 2024 - added 2 commits that reference this issue
on Dec 31, 2024 - added a commit that references this issue
on Jan 6, 2025 - added a commit that references this issue
on Feb 25, 2025 - added a commit that references this issue
on Feb 25, 2025 - added a commit that references this issue
on Apr 1, 2025 - added a commit that references this issue
on Feb 2, 2026
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:
Linked PRs