[stdlib-sig] Evolving the Standard Library

[Armin Ronacher]

Hi,

Vinay Sajip schrieb:
> Jesse's and Armin's comments above epitomise the problem. As far as I
> know (with Google's help), neither has ever bothered to post on
> python-list, python-dev, their own blogs or anywhere else what these
> "issues" with logging are.
I agree that nobody did.  And there is a reason for it, and that reason
is probably something that could be discussed in a separate thread too,
because it affects a lof stuff that is currently in the standard libary.

I looked at the logging library and my point of view is that logging is
"broken by design".  Eg: you can't fix it without breaking backwards
compatibility.

> Armin has done a fair job on describing bad points about other parts
> of the library, and fair points they are, too. Armin did once mention
> logging in a post about singletons, because logging does contain 
> singletons. However, as far as I know it does not cause problems in
> practice - I use it with Django on numerous websites and the Tornado
> webserver of FriendFeed/Facebook uses it too, apparently without the
> sky falling on its head.
I'm sorry for the wait I was expressing my disagreement with design
decisions made in the standard library and I would love to change that.
 One of the biggest griefs I have with how the standard library works it
that it does not work for me and everytime I discuss that topic with
anyone else I immediately get the feedback that "this does not happen in
the real world" or "works for me" etc.

I consider any kind of shared state a design mistake, no matter if it
may work for some people or not, the logging package is no exception.
However I have to admit that global loggers appears to be one of the
easiest solutions for the problem.

If I would have to create my own logging library, I would go a total
different part from design to implementation.  I would create a system
where the "sender" is an arbitrary Python object and the system that
handles it would have to check for its own if it may process that
message.  Only *if* there was any handler that wants to do anything with
that message, it would pull the details form the stack and format the
message.  That also would get rid of the formatters and all the other
stuff we currently have and avoids a global registry of loggers.

How would I configure a logger in a library then?  I library would
*never* by default print anything that is logged.  Default
configurations for the logging system currently are the biggest reason
for me to hate that library.  Many libraries do not even give you the
ability to turn of logging in general, and documentation for the logging
system was probably one of the reasons.  I don't know when the
"NullHandler" example appeared in the docs, but I'm sure it was not
there when I started using the logging system.

I cannot use logging for anything serious because it is slow, it has
shared state that often causes frustration, you cannot delete loggers
and much more.  Of course I do use logging for libraries because it's
the standard and the best we have got.

The only reasons (in my opinion) that logging is still around is that
it's in the stdlib, not because it's any good.  Especially when it comes
to highly optimized code in web applications you will quickly discover
that half a dozen log calls take up more CPU cycles than the actual
application code.

> This might sound a bit like a rant, but it's not meant to be - I just
> speak as  find. I'm not overly sensitive to criticism about the
> logging package; in fact I welcome *constructive* criticism which can
> help to improve it.  All of you, please feel free to head over to
> Andrii's page to post your criticisms/comments there.
I don't know how I could contribute constructive criticism.  I'm sorry
for that.

> Am I expecting too much?
I'm afraid you are.  It's hard to accept that some people think of your
system as "it just sucks", but you can't change that.  I know that
feeling from some of the stuff I wrote.  It's just a little bit worse
for you because logging is the standard (and only) one, everybody uses.
 For the stuff I wrote*, people have choice.  If they don't want to use
it, they don't have to.


Regards,
Armin

* external libraries, not distributed as part of Python except for the
  rather simple "ast" module.