This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author xmorel
Recipients methane, serhiy.storchaka, vstinner, xmorel
Date 2021-08-07.19:33:07
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1628364787.12.0.259934381701.issue43526@roundup.psfhosted.org>
In-reply-to
Content
> If working Python 3 program suddenly became emitting BytesWarning it will confuse users.

Oh yeah no I meant making it a normal warning, without needing the `-b` flag, not enabling it by default.

Because controlling / configuring warnings can be done programmatically and dynamically from inside the program, but in my understanding -b is either set or unset when calling it, if you're not setting it you're SOL. Or so I understand, I didn't find any switch accessible from inside the Python program.

> I think it would work. But it is significant amount of work (add corresponding C API, parsing and copying code, documentation, tests)

Wouldn't it just be removing the check on `-b` in the tp_str slot of bytes and bytearray?

> and for small benefit. Would not be better to filter out warnings by message?

Well yes and no, my issue remains the one from the beginning: it's quite easy to unexpectedly stringify bytes, which usually isn't what's desired. Ensuring that doesn't happen requires making sure every developer and environment (non-production at least) does run python with -b to enable the warning, which is not as easy as the software being able to set that internally (which is doable for various deprecation warnings and friends).
History
Date User Action Args
2021-08-07 19:33:07xmorelsetrecipients: + xmorel, vstinner, methane, serhiy.storchaka
2021-08-07 19:33:07xmorelsetmessageid: <1628364787.12.0.259934381701.issue43526@roundup.psfhosted.org>
2021-08-07 19:33:07xmorellinkissue43526 messages
2021-08-07 19:33:07xmorelcreate