Repository navigation
Deprecate -b and -bb CLI flags #136355
Description
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.
Activity
terryjreedy 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 TrueShould "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:
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.
pythongh-136355: Deprecate `-b` and `-bb` CLI flags in 3.15
pythongh-136355: Deprecate `-b` and `-bb` CLI flags in 3.15
picnixz commented on Jul 7, 2025
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
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.
gh-136355: Deprecate `-b` and `-bb` CLI flags in 3.15 (#136363)