Mitar added the comment:
> That's the problem, right there. I don't think the ways of doing this are
> bulletproof and require too much cooperation between third-party libraries.
Which third-party libraries? The thing I am proposing works for that particular
file you call getLogger with.
In my files I already have:
logger = logging.getLogger(__name__)
Changing that to:
logger = logging.getLogger(__name__, style='{')
seems easy and backwards compatible. How will I break any other 3rd party use
by doing this? It is my code in my file.
The only issue is that you have to make sure you are not passing object on. But
that again, is your code, so you should know what you are passing on.
We could also add logger.defaultStyle() to return the same logger, with default
style, so that you can pass it on to other function which might expect a
logger, if you want that. Or, you could define:
defaultLogger = logging.getLogger(__name__)
logger = logging.getLogger(__name__, style='{')
at the beginning of the file, and then use logger in the file, and pass
defaultLogger on.
There are so many options to address your concerns.
> I don't see how it's "really cumbersome". A simple approach is outlined in
Simple approach by everywhere in my code having to use __ now? So I have _ for
string translations, and __ for logging. This is cumbersome. Because it could
be solved by having it only once in the file. Not that I have to call it
manually everywhere in the file.
> which is also described in the documentation here:
Yes, I have read it, used it, didn't like it. So I thought about it and it
feels pretty easy to provide a capacity to have a default style applied to the
whole file. Instead of manually having to call __. It would effectively be the
same internally. Just cleaner code. Do not repeat yourself. Repeating __
everywhere is repeating myself a lot. I would like this style. Let this be
specified only once.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30995>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
