STINNER Victor <victor.stin...@gmail.com> added the comment: > It isn't good to have "-X dev" do magical things that can't already be > replicated with other options.
While it might be nice to be able to replicate -X dev "manually", I didn't try to implement that. The current implementation of this option is more complex than what I expected, especially for warnings. > Writing that issue made me realise another quirk with `-X dev` though: as a > command line option, it should really take precedence over PYTHONWARNINGS, > while remain subordinate to other explicit -W options. IMHO -X dev should change the default, but let the developer overrides options set by -X dev. For example, -X dev -bb works as expected: raise BytesWarning, and this is a test for that. There is also a test for -X dev -W error: -W error has the priority over -X dev, I did that on purpose. When I started to implement -X dev, I didn't expect so many corner cases. The problem is that the code reading the "configuration" (command line arguments, environment variables, a few configuration files, etc.) was spreaded around CPython code. You know that very well, since you wrote the PEP 432 :-) Fix the implementation of -X dev was my first motivation to work on the implementation of the PEP 432: bpo-32030. For PYTHONWARNINGS vs -X dev, I'm not sure. It's rare to use PYTHONWARNINGS. I put PYTHONWARNINGS and -W options at the same level. If someone uses PYTHONWARNINGS, warnings are likely already well understood. Overriding PYTHONWARNINGS with -X dev can be seen as a bug. Sometimes, you cannot set command line options, only environment variable. There is -X dev, but there is also PYTHONDEVMODE=1 ... ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32230> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
