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)
x

  BUT:

>>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.

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:

1. add a warning in the doc;
2. make count and flag keyword-only argument (raising a deprecation warning in 3.3 and actually change it later);
3. change the regex flags to some object that can be distinguished from ints and raise an error when a flag is passed to count;

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.

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.)

Can't you use *args and **kwargs and then raise a deprecation warning if count and/or flags are in args?
Even if enums are merged in, there might still be issues depending on their implementation.

We could do that but we would be changing the signature before adding the warning

The change would still be backwards compatible (even though inspect.signature and similar functions might return something different). Note that I'm not saying that's the best option, but it should be doable.

Please see my patch, I have changed flags to be instances of IntEnum and added a check to re.sub, re.subn and re.split. The patch contains some tests. This solution also allowed me to discover several bugs in the standard library, and I am going to create tickets for them shortly.

New changeset 767fd62b59a9 by Victor Stinner in branch 'default':
Issue bpo-11957: Explicit parameter name when calling re.split() and re.sub()
https://hg.python.org/cpython/rev/767fd62b59a9

I suggest to make the 2 last parameters of re.sub(), re.subn() and re.split() parameters as keyword-only. It will break applications using count and maxsplit parameters as index parameters, but it's easy to fix these applications if they want to support also Python 3.5.

I checked Python 2.6: the name of the maxsplit and count parameters didn't change. So it's possible to write code working on Python 2.6-3.5 if the parameter name is explicitly used:

• re.sub("a", "a", "a", count=1)
• re.subn("a", "a", "a", count=1)
• re.split("a", "a", maxsplit=1)

The flags parameter was added to re.sub(), re.subn() and re.split() functions in Python 2.7:

• https://docs.python.org/2.7/library/re.html#re.sub
• https://docs.python.org/2.7/library/re.html#re.subn
• https://docs.python.org/2.7/library/re.html#re.split

See my attached re_keyword_only.patch:

• sub(), subn(): count and flags become keyword-only parameters
• split(): maxsplit and flags become keyword-only parameters

Confusion between count/maxplit and count parameters is common, duplicated issues:

• Issue bpo-22760
• Issue bpo-17663
• Issue bpo-15537
• Issue bpo-12875
• Issue bpo-12078
• Issue bpo-11947

See also issue bpo-13385 which proposed an explicit "re.NOFLAGS flag".

Thank you for your patch Valentina. But it makes flags combinations not pickleable.

>>> import re, pickle
>>> pickle.dumps(re.I|re.S, 3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
_pickle.PicklingError: Can't pickle <enum 'SubFlag'>: attribute lookup SubFlag on sre_constants failed
>>> pickle.dumps(re.I|re.S, 4)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
_pickle.PicklingError: Can't pickle <enum 'SubFlag'>: attribute lookup BaseFlags.__or__.<locals>.SubFlag on sre_constants failed

And I'm afraid that creating new class in the "|" operator can affect performance.

As for 767fd62b59a9, I doubt that changing positional arguments to keyword argumennts in tests is justified. This can hide a bug.

And again about patch_11957. I afraid that testing isinstance(count, sre_constants.BaseFlags) on every re.sub() call will hit performance too.

I agree about 767fd62b59a9, there should be tests for args passed both by position and as keyword args.

Serhiy, do you think the enum solution is worth pursuing, or is it better to just turn those args to keyword-only (after a proper deprecation process)?

I think that the enum solution is worth pursuing, and that we need general
class which represents the set of specified named flags. I'm working on
implementation of enum.IntFlags.

I'd like to propose that we merge Serhiy's second patch, which deprecates passing count and maxsplit arguments as positional arguments.

• There is a slight slowdown for cases where the arguments are already passed by keyword, which is larger in the deprecated case. However, this is easy to work around by using explicitly re.compile()'d patterns, which is already common in performance-sensitive code.
• re.sub() doesn't substitute for all words with the replacement in the string when re.IGNORECASE is used and counter not specified #99918 (comment) counts sixteen equivalent issues which have been opened against CPython. This is clearly a substantial and recurring confusion, and while linters have recently started flagging this I would prefer an upstream solution which can help new programmers too.
• gh-95065: Add Argument Clinic support for deprecating positional use of parameters #95151 suggests that there is appetite for migrating positional-or-keyword params to keyword-only in the standard library when the status quo is confusing or error-prone.

If necessary, I'd be happy to write or organize a PR.

Thanks for bumping this, I'd forgotten about it. As you can tell by my previous comments, I think this is something we need to do. Just fixed another one of these a couple weeks ago. I'll open a PR with Serhiy's patch

It is an old patch and it required polishing.