Issues to be aware of when using global logging in Python

This article mainly describes the use of the global log in Python need to pay attention to the problem, the author by the use of Uliweb problems encountered when the global log error resolution, the need for friends can refer to the

After the soap WebService was developed using Uliweb, the Werkzeug log was inexplicably lost when the Uliweb was started.

Normal log:

The code is as follows:

[INFO] * Loading debuggedapplication ...

[INFO] * Running on Http://localhost:8000/

[INFO] * Restarting with Reloader

[INFO] * Loading debuggedapplication ...

Log of exception:

The code is as follows:

[INFO] * Loading debuggedapplication ...

[INFO] * Loading debuggedapplication ...

In fact, Werkzeug related INFO and the following levels of the log are all out of sight, this is very strange, so decisively submitted issue

And I created a new project and app, and no log lost problems, so I suspect that because I upgraded from Uliweb 0.1.3 to 0.1.4 caused, my project is created using 0.1.3, and did not pay attention to the issue of the log before, but get Limodou reply, I deny This point

Uliweb does not generate anything like Django manage.py when creating a project, that is, settings.py and other configuration files and startup files that are not version-independent.

To think about it, the difference between my project and the newly created project is that Settings.ini is enriched and then used Pysimplelib, OK, trace it from the source.

I read the Uliweb built-in ZERKZEUG code, create the log here is very clear

uliweb/lib/werkzeug/serving.py

The code is as follows:

112 If not logging.root.handlers and _logger.level = = logging. NOTSET:

113 _logger.setlevel (Logging.info)

114 Handler = logging. Streamhandler ()

_logger.addhandler (handler) [code]

When a Handler is defined in the global logging.root or Werkzeug does not have a log level defined, Werkzeug sets its logger log level to info, and the location where the Werkzeug log is printed, happens to use the info level

[Code] [INFO] * Running on Http://localhost:8000/

[INFO] * Restarting with Reloader

That is, because the other logging handler have been defined, causing the Werkzeug log to be unable to output

The results under grep pysimplelib

The code is as follows:

./client.py:33:logging.basicconfig (format= '% (levelname) s:% (message) s ', level=logging. WARNING)

./simplexml.py:27:logging.basicconfig (format= '% (levelname) s:% (message) s ', level=logging. WARNING)

./transport.py:30:logging.basicconfig (format= '% (levelname) s:% (message) s ', level=logging. WARNING)

Well, that's what this guy was up to. Comment out these three lines of code, WERKZEUG log Normal output

That said, this should not be regarded as a uliweb problem, Pysimplesoap Library to modify the overall design, it seems that should give it to mention a issue is, this issue should be able to shut down.

Here's a workaround, add in Apps/settings.ini

The code is as follows:

[LOG. Loggers]

Werkzeug = {' Propagate ': 0, ' level ': ' Info ', ' format ': ' Format_simple '}

Of course, it is recommended that Limodou set the log level of Zerkzeug in Default_settings.ini to info by default, because the problem is so bizarre, after all, the default log level in Werkzeug is info.

Well, to recap, because the global log level is overridden in Pysimplesoap, the Werkzeug cannot enter a log below warning, so if we were to open the Python library, we would still be able to hit the log under our own namespace and not touch the global Logging settings, this can cause trouble to others.