[issue43526] Programmatic management of BytesWarning doesn't work for native triggers.

STINNER Victor added the comment: > If this is intended behaviour, which seems to be the case according to > ncoghlan's comment https://bugs.python.org/issue32230#msg307721, it should be > clearly documented, as it's rather frustrating. The -b command line documentation is not explicitly eno

[issue43526] Programmatic management of BytesWarning doesn't work for native triggers.

STINNER Victor added the comment: While you should not do that at home ;-), it's now *technically* possible to change the BytesWarning flag at runtime using a a *private* *internal* API: $ ./python Python 3.11.0a2+ (heads/remove_asyncore:010015d2eb, Nov 11 2021, >>> "unicode" == b"bytes" Fal

[issue43526] Programmatic management of BytesWarning doesn't work for native triggers.

Gregory P. Smith added the comment: clarification after poking around: s/all/a lot/ - YouTube used it to help their Python 3 migration. Regardless, the env. var has been useful. -- ___ Python tracker _

[issue43526] Programmatic management of BytesWarning doesn't work for native triggers.

Gregory P. Smith added the comment: fwiw, at work we modified our interpreter to treat PYTHONBYTESWARNING=1 or 2 as if -b or -bb were passed. All of our tests run by default with a PYTHONBYTESWARNING=2 in their environment. -- nosy: +gregory.p.smith

[issue43526] Programmatic management of BytesWarning doesn't work for native triggers.

Xavier Morel added the comment: > 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 progr

[issue43526] Programmatic management of BytesWarning doesn't work for native triggers.

Serhiy Storchaka added the comment: > And though I did not check, I expect the `-b` flag exists mostly because of > the performance impact of the warning any time bytes are checked for > equality, but surely that impact would be limited and probably not very > relevant for the stringificatio

[issue43526] Programmatic management of BytesWarning doesn't work for native triggers.

Xavier Morel added the comment: And though I did not check, I expect the `-b` flag exists mostly because of the performance impact of the warning any time bytes are checked for equality, but surely that impact would be limited and probably not very relevant for the stringification of bytes a

[issue43526] Programmatic management of BytesWarning doesn't work for native triggers.

Xavier Morel added the comment: > I am not against documenting the behavior of -b and BytesWarning clearly. I > don't think that anyone would be against. Just somebody have to provide a PR. Right but what about the ability to enable warning on stringification without enabling the warning on

[issue43526] Programmatic management of BytesWarning doesn't work for native triggers.

Serhiy Storchaka added the comment: I am not against documenting the behavior of -b and BytesWarning clearly. I don't think that anyone would be against. Just somebody have to provide a PR. Explicitly repr-ing a bytes instance does not produce a warning, and never produced, so I don't unders

[issue43526] Programmatic management of BytesWarning doesn't work for native triggers.

Xavier Morel added the comment: Serhiy an other question (because I've encountered it *again*), do you think it'd be possible to split out the specific warning of stringifying (but *not* explicitely repr-ing) a bytes instance from everything else? There are use-cases for it, but I think it's

[issue43526] Programmatic management of BytesWarning doesn't work for native triggers.

Xavier Morel added the comment: > In normal circumstances you should never deal with BytesWarning. The -b > option is only used for testing your program for some possible bugs caused by > migration from Python 2. If your program always worked only with Python 3, > the -b option has no use for

[issue43526] Programmatic management of BytesWarning doesn't work for native triggers.

Change by Terry J. Reedy : -- versions: +Python 3.10 -Python 3.6, Python 3.7 ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue43526] Programmatic management of BytesWarning doesn't work for native triggers.

Serhiy Storchaka added the comment: Yes, it is intended behaviour. BytesWarning is only emitted when you set a special internal flag (by the -b option). Warning filters control what happen with that warning later: be it ignored, printed, or converted to exception. In normal circumstances you

[issue43526] Programmatic management of BytesWarning doesn't work for native triggers.

Xavier Morel added the comment: Addendum: is there a way to force `-b` from within the running Python program? -- ___ Python tracker ___ __

[issue43526] Programmatic management of BytesWarning doesn't work for native triggers.

New submission from Xavier Morel : When setting `BytesWarning` programmatically (via the warnings API), though the `warnings.filters` value matches what's obtained via `python -b` and an explicit `warnings.warn` trigger will trigger, "native" triggers of the warning fail to trigger properly: