[issue30995] Support logging.getLogger(style='{')

[Vinay Sajip]

Changes by Vinay Sajip :


--
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30995] Support logging.getLogger(style='{')

[Raymond Hettinger]

Raymond Hettinger added the comment:

> logger.info( f" {logger.name:s} {logger.module:s} " ) 
>
> this could be supported with full backward compatibility 
> with very little effort.   
>
> Am I missing something?

One issue is that some of that data isn't known until the logging.info() call 
is made. And accessing the data before the call would bypass the internal 
locks, potentially causing race conditions.

Another issue is that having to use an attribute lookup for every variable 
isn't fast and doesn't look very nice (making this feature awkward to use when 
the whole goal is to improve usability).

FWIW, you can already use f-strings for all of your local data.  The logging 
internal data tends to be already set upsteam in the configuration format 
(which is only done once):

# Formatting is only done once so %-formatting isn't problematic
logging.basicConfig(
level = logging.INFO,
format = '%(levelname)-8s | %(asctime)s | %(message)s',
filename = 'demo.log',
)

# In the body of the code, use f-strings for your local data:
logging.info(f'There are {active_users} in {session_name}')

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30995] Support logging.getLogger(style='{')

[Steven Warwick]

Steven Warwick added the comment:

sorry, I meant the following:

logger.info( " {:s} {:s} ".format(logger.name, logger.module ) )

or 

logger.info( f" {logger.name:s} {logger.module:s} " ) 

this could be supported with full backward compatibility with very little 
effort.   

Am I missing something?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30995] Support logging.getLogger(style='{')

[Raymond Hettinger]

Raymond Hettinger added the comment:

[Vinay Sajip]
> I don't think the ways of doing this are bulletproof and 
> require too much cooperation between third-party libraries.

I concur with all of Vinay's comments.  

If logging were being redesigned from scratch, it would likely use new-style 
formatting everywhere.  But, it is already deployed and widely adopted.  Trying 
to make it support two-ways-to-do-it would likely create more problems than it 
solves.

Vinay, do you want to reject and close this proposal?

--
assignee:  -> vinay.sajip
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30995] Support logging.getLogger(style='{')

[Steven Warwick]

Steven Warwick added the comment:

you probably have already considered this, but I just wanted to ask if it might 
be worth considering turning the problem "upside down" to make things easier.

  I'm interpreting the problem that there are variables we'd like to add to the 
output log that are provided inside the logger, which is why we need to use a 
specific type of format string to make sure you add them correctly.   If 
instead, these same variables are simply exposed as logger attributes, we could 
just create the complete formatted string when we call the logger.  

logger.info( " {:s} {:s} ", logger.name, logger.module ) 

does this make any sense?

--
nosy: +sdwarwick

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30995] Support logging.getLogger(style='{')

[Vinay Sajip]

Vinay Sajip added the comment:

> Which third-party libraries?

> It is my code in my file.

If a feature is added to logging, anyone can use it. If people put 
style-specific loggers in libraries they write, and other people then use those 
libraries, then there may be a need for them to worry about which style the 
library loggers use. Perhaps you don't log to loggers in other people's 
modules, but it's something which is allowed in logging, and useful in some 
scenarios.

> Yes, I have read it, used it, didn't like it.

These things are matters of opinion and taste. It doesn't seem cumbersome to 
me, but it seems cumbersome to you. Well, you can subclass Logger to add the 
new functionality and use it in your code. Why don't you try doing that?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30995] Support logging.getLogger(style='{')

[Mitar]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30995] Support logging.getLogger(style='{')

[Vinay Sajip]

Vinay Sajip added the comment:

> You only have to make sure they do not use this logger without knowing about 
> new format, which can be done in various ways (like prefixing the name of the 
> logger, for example).

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.

> using non-legacy formatting in logging message is really cumbersome

I don't see how it's "really cumbersome". A simple approach is outlined in

http://plumberjack.blogspot.co.uk/2010/10/supporting-alternative-formatting.html

So that logging using brace formatting could be as simple as 

logger.misc(__('User {} logged in', username))

which is also described in the documentation here:

https://docs.python.org/3.3/howto/logging-cookbook.html#use-of-alternative-formatting-styles

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30995] Support logging.getLogger(style='{')

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +vinay.sajip

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30995] Support logging.getLogger(style='{')

[Mitar]

New submission from Mitar:

Currently, using non-legacy formatting in logging message is really cumbersome. 
I think a new style could be supported much easier using the following:

logger = logging.getLogger(style='{')
logger.misc('User {} logged in', username}

This is both backwards compatible, and does not interfere with 3rd party 
packages which might use a different logger with different style. You only have 
to make sure they do not use this logger without knowing about new format, 
which can be done in various ways (like prefixing the name of the logger, for 
example).

See https://bugs.python.org/issue14031 for more information, where this has 
also been proposed but not really commented upon.

--
components: Library (Lib)
messages: 298883
nosy: mitar
priority: normal
severity: normal
status: open
title: Support logging.getLogger(style='{')
type: enhancement
versions: Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com