>
> But if the libraries are already doing logging, can't I already do that?
>
> And if the libraries aren't doing logging, this won't magically add
> logging to them, will it?
>
As a best practice, libraries log into a NullHandler to avoid setting up
the root logger, and to prevent sending
On Sat, Jun 06, 2020 at 09:31:36PM +0300, Bar Harel wrote:
> >
> > 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
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?
You would be
On Sat, Jun 6, 2020 at 6:46 AM Steven D'Aprano wrote:
> 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:
>
>
>
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:
Hey Remi,
I've started working on it the other day, but unfortunately had
difficulties with my development environment after suffering a hard drive
failure.
Haven't tried again since then.
I've opened a quick bpo - 40886.
Since my dev environment is still messed up and VStudio kills me with
Did this idea ever went anywhere? I thought I saw a bpo issue for this but I
can't find it anymore and it's not present in 3.8 or 3.9 NEWS nor in master as
far as I can tell.
I think it would be very useful, while it's possible to use argparse to have an
argument to set it I've found that many
Last resort logger works only if no handlers are set.
NullHandler for example is used on most libraries in order to prevent
setting up the logging system, but it can cause errors not to show.
Also, LastResort is set for the "Warning" level. -L will give you
the flexibility you need in order to
Ok... Though some kind of logging configuration, even a default one, is always
present. For example, when logging.info() module method --or some one similar--
is called for the first time, it creates a basic logger with a last resort
handler if none exists --at least up to my knowledge. So
So, are you suggesting that -L must create a basic logger with the given
logging level? Is it right? It can work...
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
-L will act as logging.basicConfig(level=level), but on a temporary
basis, much like -W sets warning's filters.
If you don't setup logging, or don't want to (cause you're checking some
library functions), this will be super handy.
If you do setup logging, it has the same caveats as setting the
On 2020-02-21 08:45, jdve...@gmail.com wrote:
Nice idea... in principle.
But, what if my program has several loggers with several handlers each having
its own logging info level? Would the Python's interpreter CLI argument (or the
ENV variable) override all loggers and handlers logging
Nice idea... in principle.
But, what if my program has several loggers with several handlers each having
its own logging info level? Would the Python's interpreter CLI argument (or the
ENV variable) override all loggers and handlers logging levels? Why should CLI
/ ENV override those loggers
+1
On Thu, Feb 20, 2020 at 11:46 Alex Hall wrote:
> Christopher Barker wrote:
> > I think it’s a “Bad Idea” to use an environment variable — who knows what
> > Python script may be running on a given system?
> > But a standard command line argument to the interpreter could be useful.
>
> Can
> Let's plan a cmdline argument then.
> Should we go for -L much like -W?
Yeah, I think a command-line argument is much more reasonable, less likely
to cause issues with other implementations of logging configuration, and
more practically useful. I'd be +1 on something like a `-L`.
On Thu, Feb
Christopher Barker wrote:
> I think it’s a “Bad Idea” to use an environment variable — who knows what
> Python script may be running on a given system?
> But a standard command line argument to the interpreter could be useful.
Can you clarify what the concern is about other Python scripts
I think it’s a “Bad Idea” to use an environment variable — who knows what
Python script may be running on a given system?
But a standard command line argument to the interpreter could be useful.
-CHB
On Thu, Feb 20, 2020 at 8:51 AM Mike Miller
wrote:
>
> On 2020-02-19 17:12, Bar Harel wrote:
On 2020-02-19 17:12, Bar Harel wrote:
Another idea I've had that may be of use:
PYTHONLOGGING environment variable.
Setting PYTHONLOGGING to any log level or level name will initialize
logging.basicConfig() with that appropriate level.
Another option would be that -x dev or a different -x
>
> > If you want it only temporarily for debugging purposes, or permanently
> for all scripts in your system, it's not really feasible.
>
> Hmm, I'm not sure that I like the idea of overriding the default logging
> level being set system-wide, or that there would be an especially strong
> use
[re-sending this since I forgot to CC the list]
> Unfortunately, there is no logging.loglevel attribute.
> At the moment, the only way of doing this is modifying the program,
parsing input parameters and setting up the logging system.
Indeed, that's why I clarified in the follow-up message;
Thanks Kyle for the feedback :-)
Unfortunately, there is no logging.loglevel attribute.
At the moment, the only way of doing this is modifying the program, parsing
input parameters and setting up the logging system.
If you want it only temporarily for debugging purposes, or permanently for
all
> This can already be done from the command line through --log=LEVEL, which
sets the logging.loglevel attribute. In the how-to section of the docs,
this is demonstrated in the following example:
Note: "loglevel" is an arbitrary name, but this can be implemented
trivially with something like
> Setting PYTHONLOGGING to any log level or level name will initialize
logging.basicConfig() with that appropriate level.
This can already be done from the command line through --log=LEVEL, which
sets the logging.loglevel attribute. In the how-to section of the docs,
this is demonstrated in the
23 matches
Mail list logo
