I think the first thing that needs to be done, before creating a bpo issue, is to get consensus that it's both a plausible idea and a good idea, and I don't think that the discussion did either.
Discussion starts here:
Bar's initial reason for this:
"Will be useful mostly for debugging purposes instead of temporarily modifying the code."
Okay, but how does that work? I have a script:
# myscript.py print("Hello world")
and I want to add logging to it. So I set the environment variable, or use the proposed -L command line switch, and call the script:
PYTHONLOGGING=mylogfile python myscript.py
but what exactly gets logged?
It's one thing to say that the interpreter takes care of importing logging and setting up a basic logger, and that's great, but I still have to import logging and call the `logging.info(...)` functions, so what does this proposal give us, *in detail* please, and how do I use it?
I've read the entire thread and there is lot of detail there that seems to be written for expert users of logging. If you're an expert user of logging, you probably don't need an environment variable, or you can handle it yourself with os.environ.get('LOGLEVEL').
How is this going to impact basic and intermediate users of logging?
The tutorial warns: "As [logging.basicConfig] is intended as a one-off simple configuration facility, only the first call will actually do anything: subsequent calls are effectively no-ops."
So what happens if I have a script that explicitly calls basicConfig but I accidentally run it with the -L switch or PYTHONLOGGING?
E.g. I may have an alias 'python=python -L', or I may have set the environment variable in a shell and then forgotten it. I sometimes have shells open for weeks at a time, I'm going to be terribly confused if myscript logs correctly in one open shell but not in another because of an environment variable I set two weeks earlier.