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