[issue18689] add argument for formatter to logging.Handler and subclasses in logging module

[Derek Wilson]

Derek Wilson added the comment:

> It's not an ideal world. Sorry, but I think this change is too invasive to 
> consider.

Obviously its not ideal, which is why my suggestion doesn't require intelligent 
3rd party libraries and is explicitly not invasive. As I said in my previous 
comment, using a keyword only argument means: "If [3rd party libraries] haven't 
[properly handled **kwargs] then nothing changes for them and they just support 
exactly the same features they supported previously."

The upshot is it is not invasive and no one needs to care unless they want to 
use the new functionality.

As far as this change being needed or not, nothing "needs" to be made easier to 
use if it is possible to use it. But that isn't really a good reason not to 
improve things.

I honestly think that part of the reason this hasn't come up is because the 
advanced features of logging are so difficult to use that people just don't use 
it to its fullest extent. On top of that, when learning python, logging is way 
harder to grok than it should be for someone new to python.

Logging and unittest are two of the most important libraries for new 
pythonistas to learn, but they are also some of the most nebulous, stateful, 
magical, java-like, complicated, verbose, and difficult to master packages in 
python.

They've been around for a while for sure - but doesn't that rather mean that 
they could use an update?

I'm willing to submit a patch if it has the smallest chance of being considered?

--
versions: +Python 3.6 -Python 3.4

___
Python tracker 

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

[issue18689] add argument for formatter to logging.Handler and subclasses in logging module

[Derek Wilson]

Derek Wilson added the comment:

dictConfig and fileConfig are nice for static needs, but when I want to quickly 
enable a complex (but not complicated) logging flow I find it just as tedious 
as the current situation with the direct API.

 ... as at the very least every handler would need to be changed to 
 accommodate the new kwarg

Adding a keyword only argument to the base handler and the other handler 
classes is a nearly trivial change in terms of lines and complexity of the code.

 Also, this isn't going to work for third-party handlers which are out there 
 already, since they won't necessarily recognise a new kwarg.

I don't see that as a problem. If 3rd party handlers are intelligent then they 
will include **kargs in their __init__ and pass that forward to the 
initialization of their parent. If they haven't done so then nothing changes 
for them and they just support exactly the same features they supported 
previously.

--
status: pending - open

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18689
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18689] add argument for formatter to logging.Handler and subclasses in logging module

[Vinay Sajip]

Vinay Sajip added the comment:

 If 3rd party handlers are intelligent

It's not an ideal world. Sorry, but I think this change is too invasive to 
consider. I can't believe this change is really needed - logging has been 
around since 2002 and this has never been raised before.

--
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18689
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18689] add argument for formatter to logging.Handler and subclasses in logging module

[Vinay Sajip]

Vinay Sajip added the comment:

I suggest that the declarative configuration approach of 
logging.config.dictConfig() be used for configurations which can't be handled 
by basicConfig().

I don't propose to enhance the Handler API as suggested, as at the very least 
every handler would need to be changed to accommodate the new kwarg. Also, this 
isn't going to work for third-party handlers which are out there already, since 
they won't necessarily recognise a new kwarg.

--
nosy: +vinay.sajip
resolution:  - wont fix
status: open - pending

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18689
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18689] add argument for formatter to logging.Handler and subclasses in logging module

[Derek Wilson]

New submission from Derek Wilson:

It is common when setting up a logger to create both a handler and a formatter. 
Nice format strings make logging better. Like this:

 fmt_string = %(asctime)s [%(levelname)-9s] %(name)s: %(message)s

We would use it like so: 

 from logging import getLogger, StreamHandler, Formatter
 logger = getLogger('mypackage.mymodule')
 handler = StreamHandler()
 formatter = Formatter(fmt_string)
 handler.setFormatter(formatter)
 logger.addHandler(handler)
 logger.warning('she called out a warning...')

But its nice to separate adding handlers from using loggers. so in mymodule I 
might do:

 logger = getLogger('mypackage.mymodule')
 logger.warning('do not pass go...')

and in whatever entry point cares about logging from mypackage (like a cli or 
another module importing my package that wants log data) I would do:

 base_logger = getLogger('mypackage')
 handler = StreamHandler()
 formatter = Formatter(fmt_string)
 handler.setFormatter(formatter)
 base_logger.addHandler(handler)

but usually, at this point, i don't care about this base_logger at all and i've 
got a bunch of refs to things i don't need anymore - the only purpose of all 
this code is to handle any logging that may be done elsewhere in the package.

If handlers allowed passing in a formatter into __init__, then we could reduce 
the above to something like this:

 getLogger('mypackage').addHandler(StreamHandler(
fmt=Formatter(fmt_string)))

Using a kwarg would make it so we don't need to worry about existing argument 
order so that should be completely backward compatible.

It'd be extra friendly if Handler could introspect fmt and see if it is an 
instance str and if so create a Formatter in itself ... that way we could do:

 getLogger('mypackage').addHandler(StreamHandler(fmt=fmt_string))

This would reduce the barrier to entry to customizing logging functionality and 
might go a long way toward increasing effective use of the same.

--
components: Library (Lib)
messages: 194706
nosy: underrun
priority: normal
severity: normal
status: open
title: add argument for formatter to logging.Handler and subclasses in logging 
module
type: enhancement
versions: Python 3.4

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18689
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com