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.
mrabarnett commented on May 6, 2011
mrabarnettmannequin
Mannequin
More actions
Something like "<re.Flag ASCII | IGNORE>" may be more Pythonic.
I like option #2, and I was thinking of working on it today, poke me if anyone has a problem with this.
mmilkin commented on Apr 13, 2013
mmilkinmannequin
Mannequin
More actions
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.)
Activity
mindauga commented on Apr 29, 2011
re.sub don't substitute not ASCII characters:
Python 2.7.1 (r271:86832, Apr 15 2011, 12:11:58) Arch Linux
ericvsmith commented on Apr 29, 2011
The 4th parameter to re.sub() is a count, not flags.
ezio-melotti commented on Apr 30, 2011
Since 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:
terryjreedy commented on May 6, 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.
mrabarnett commented on May 6, 2011
Something like "<re.Flag ASCII | IGNORE>" may be more Pythonic.
terryjreedy commented on May 7, 2011
Agreed, if we go that route.
merwok commented on May 23, 2011
I’d favor 1) or 2) over 3). Ints are short and very commonly used for flags.
ezio-melotti commented on Sep 5, 2011
See also bpo-12888 for an error in the stdlib caused by this.
mmilkin commented on Apr 13, 2013
I like option #2, and I was thinking of working on it today, poke me if anyone has a problem with this.
mmilkin commented on Apr 13, 2013
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
test.py: pass "count" to re.sub() with kwarg
test.py: pass "count" to re.sub() with kwarg
Remove deprecated use of count as positional arg
Remove deprecated use of count as positional arg
test.py: pass "count" to re.sub() with kwarg
test.py: pass "count" to re.sub() with kwarg
test.py: pass "count" to re.sub() with kwarg
crashpad: fix update.py DeprecationWarning under Python 3.13
Fix Python 3.13 re DeprecationWarning: pass count and flags by keyword
Fix Python 3.13 re DeprecationWarning: pass count and flags by keyword
'maxsplit' should not be passed as positional argument
'maxsplit' should not be passed as positional argument
'maxsplit' should not be passed as positional argument
artiq_flash: Fix incorrect re.sub() call