Deprecate `-b` and `-bb` CLI flags

[sobolevn]

Feature or enhancement

Discussion link: https://discuss.python.org/t/consider-deprecating-and-eventually-removing-b-cli-flag/96903

Currently -b and -bb CLI options do not provide much benefit, but has several corner-cases where they require some work-arounds.

My plan to deprecate them:

• Use regular stderr output about a deprecation, do not raise a real DeprecationWarning object. Why? Because initconfig.c does not have GIL yet to call C-API and real warnings can mess things up, since -b is also warnings-related. I guess docs + stderr output will be good enough. Downsides: warning filtering and -We and -Wi won't affect this warning.
• 2 versions should be enough for the deprecation, since the only thing required is to simply remove -b from the command line args

Future plans:

• After the deprecation will end in 3.17, I plan to remove -b and -bb options (there's an alternative to make them no-op, but it can be suprising for end users that they do nothing)
• I also plan to remove code paths that require sys.flags.bytes_warning to be set, no warnings will be produced as of 3.17

All other machinery will be kept as-is.

Linked PRs

• gh-136355: Deprecate -b and -bb CLI flags in 3.15 #136363

[terryjreedy]

-b     : issue warnings about converting bytes/bytearray to str and comparing
         bytes/bytearray with str or bytes with int. (-bb: issue errors)

[terryjreedy]

Without testing, t is not clear to me just when a warning/error will be issued, such as in the following.

>>> b'' == ''
False
>>> str(b'abc')
"b'abc'"
>>> b'abc'.decode()
'abc'
>>> ord('a')
97
>>> b'a' == 97
False
>>> b'a'[0] == 97
True

Should "x and y or z" be interpreted as "x or y or z" miswritten or parsed as "(x and y [both required in one expression to provode a warning]) or z" or "x and (y or z)" or something else.

Perhaps you should ask on discuss whether anyone makes use of these options.

[sobolevn]

Usage:

>>> str(b'')
Traceback (most recent call last):
  File "<python-input-2>", line 1, in <module>
    str(b'')
    ~~~^^^^^
BytesWarning: str() on a bytes instance

>>> b'a' == 'a'
Traceback (most recent call last):
  File "<python-input-0>", line 1, in <module>
    b'a' == 'a'
BytesWarning: Comparison between bytes and string

>>> b'1' == 1
Traceback (most recent call last):
  File "<python-input-1>", line 1, in <module>
    b'1' == 1
BytesWarning: Comparison between bytes and int

Perhaps you should ask on discuss whether anyone makes use of these options.

Yes, I asked about it already :)
No replies so far.

For me, it looks like mypy solves all these problems way more useful than -b does.

[picnixz]

there's an alternative to make them no-op, but it can be suprising for end users that they do nothing

Having a no-op is better for compatibility purposes. It's common that shell utilities retain some options just to prevent scripts for failing and I think having a no-op would be fine. But OTOH, this adds a maintenance burden and it also prevents future usage of such letter.

Personally, I never used that option. Is there a way to enable such warnings with env vars? if so, then it's ok to remove the support entirely. Otherwise, using a linter is probably better as well.

[vstinner]

Use regular stderr output about a deprecation, do not raise a real DeprecationWarning object. Why? Because initconfig.c does not have GIL yet to call C-API and real warnings can mess things up, since -b is also warnings-related.

You can emit the warning in Python/pylifecycle.c and there you can emit a regular DeprecationWarning.

[serhiy-storchaka]

There was a suggestion to make these options no-ops. There is a precedence -- the -t option.

In that case runtime warnings would make more harm. If the end goal is to make them no-ops, we should not inconvenience people in the meantime.