GeezerVison is showing github.com — Deprecate `-b` and `-bb` CLI flags · Issue #136355 · python/cpython
Deprecate -b and -bb CLI flags #136355DescriptionFeature 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
Reacted by Sergey Miryanov Activityterryjreedy commented on Jul 7, 2025 -b : issue warnings about converting bytes/bytearray to str and comparing
bytes/bytearray with str or bytes with int. (-bb: issue errors)
terryjreedy commented on Jul 7, 2025 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 commented on Jul 7, 2025 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 commented on Jul 7, 2025
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 commented on Jul 7, 2025
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 commented on Jul 8, 2025 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. sobolevn commented on Jul 8, 2025 No-op might be safer. No breakages, no refactoring, no warnings. Reacted by Victor Stinner
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|