Skip to content

Deprecate -b and -bb CLI flags #136355

Closed
Closed
Deprecate -b and -bb CLI flags#136355
Assignees
sobolevn
Labels
interpreter-core(Objects, Python, Grammar, and Parser dirs)topic-sysconfigtype-featureA feature request or enhancement

Description

@sobolevn
sobolevn
opened on Jul 7, 2025

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

Activity

  1. sobolevn
    self-assigned this
    on Jul 7, 2025
  2. sobolevn
    added
    type-featureA feature request or enhancement
    interpreter-core(Objects, Python, Grammar, and Parser dirs)
    topic-sysconfig
    3.15bugs and security fixes
    on Jul 7, 2025

  3. terryjreedy commented on Jul 7, 2025

    @terryjreedy
    terryjreedy
    on Jul 7, 2025
    Member
    -b     : issue warnings about converting bytes/bytearray to str and comparing
         bytes/bytearray with str or bytes with int. (-bb: issue errors)

  4. terryjreedy commented on Jul 7, 2025

    @terryjreedy
    terryjreedy
    on Jul 7, 2025
    Member

    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.

  5. sobolevn commented on Jul 7, 2025

    @sobolevn
    sobolevn
    on Jul 7, 2025
    MemberAuthor

    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.

  6. sobolevn
    added 2 commits that reference this issue on Jul 7, 2025

    pythongh-136355: Deprecate `-b` and `-bb` CLI flags in 3.15

    bac0293

    pythongh-136355: Deprecate `-b` and `-bb` CLI flags in 3.15

    499343c

  7. picnixz commented on Jul 7, 2025

    @picnixz
    picnixz
    on Jul 7, 2025
    Member

    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.

  8. picnixz
    removed
    3.15bugs and security fixes
    on Jul 7, 2025

  9. vstinner commented on Jul 7, 2025

    @vstinner
    vstinner
    on Jul 7, 2025
    Member

    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.

  10. serhiy-storchaka commented on Jul 8, 2025

    @serhiy-storchaka
    serhiy-storchaka
    on Jul 8, 2025
    Member

    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.

  11. sobolevn commented on Jul 8, 2025

    @sobolevn
    sobolevn
    on Jul 8, 2025
    MemberAuthor

    No-op might be safer. No breakages, no refactoring, no warnings.

  12. sobolevn
    added a commit that references this issue on Sep 14, 2025

    gh-136355: Deprecate `-b` and `-bb` CLI flags in 3.15 (#136363)

    1c984ba
  13. sobolevn
    closed this as completedon Sep 14, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

interpreter-core(Objects, Python, Grammar, and Parser dirs)topic-sysconfigtype-featureA feature request or enhancement

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions