[WIP] gh-89621: re.subn?(): raise error when RegexFlag is wrongly used as count argument

[ghost]

@serhiy-storchaka

In re.subn?() functions, some users wrongly use RegexFlag as the count parameter.

Many invalid bug reports can be found (#89621, #86639, #85930, #85830, #79724, #75110, #73091, #72038, #70542, #66949, #61863, #59972, #56287, #56166, #56156, #55471). Maybe there are some code still generating incorrect data silently.

This PR is just a draft, not completive. I didn't expect this PR to be merged.
See if you agree with this method. Compared to changing count to a keyword only parameter, it keeps compatibility, and the overhead is very small.

If you want to make a better PR, please make it.
IMO making such PR is faster & easier than reviewing.
Or let me know if you want me to perfect this PR.

[ghost]

Another method is implementing re.subn?() functions in C, and check type(count) != RegexFlag there. In this way, Pattern.subn?() have no overhead at all.

def sub(pattern, repl, string, count=0, flags=0):
    return _compile(pattern, flags).sub(repl, string, count)

def subn(pattern, repl, string, count=0, flags=0):
    return _compile(pattern, flags).subn(repl, string, count)

[serhiy-storchaka]

Just keep the existing error. ValueError is wrong exception for wrong type, and the raised exception can be for example OverflowError.

[serhiy-storchaka]

Look at the code for the n format unit in getargs.c. You should reproduce it.

[serhiy-storchaka]

It could be easier to implement a custom converter (see docs for PyArg_Parse, format unit O&).

    count: object(converter="my_converter_for_ssize_t_except_RegexFlag") = 0

[luxedo]

I have just fallen into this trap. It's very easy to get cocky and forget to pay attention to the count argument.

Any chance of at least adding type hints to the re library or would this break too many things?