When configuring the logging stack, accept already built filters (or
just callables) in the filters array of loggers and handlers.
This facilitates passing quick callables as filters.
Automerge-Triggered-By: GH:vsajip
The list lookups become a big burden for very long lists.
This patch changes the "happy flow" path of 2 lookups into 1 lookup.
Automerge-Triggered-By: GH:vsajip
* bpo-42644: Validate values in logging.disable()
Technically make the value of manager a property that checks and convert
values assigned to it properly. This has the side effect of making
`logging.disable` also accept strings representing the various level of
warnings.
We want to validate the type of the disable attribute at assignment
time, as it is later compared to other levels when emitting warnings and
would generate a `TypeError: '>=' not supported between ....` in a
different part of the code base, which can make it difficult to track
down.
When assigned an incorrect value; it will raise a TypeError when the
wrong type, or ValueError if an invalid str.
Co-authored-by: Andrew Svetlov <andrew.svetlov@gmail.com>
The logging.FileHandler class now keeps a reference to the builtin
open() function to be able to open or reopen the file during Python
finalization.
Fix errors like:
Exception ignored in: (...)
Traceback (most recent call last):
(...)
File ".../logging/__init__.py", line 1463, in error
File ".../logging/__init__.py", line 1577, in _log
File ".../logging/__init__.py", line 1587, in handle
File ".../logging/__init__.py", line 1649, in callHandlers
File ".../logging/__init__.py", line 948, in handle
File ".../logging/__init__.py", line 1182, in emit
File ".../logging/__init__.py", line 1171, in _open
NameError: name 'open' is not defined
The 'extra' argument is not always used by custom logger adapters. For
example:
```python
class IndentAdapter(logging.LoggerAdapter):
def process(self, msg, kwargs):
indent = kwargs.pop(indent, 1)
return ' ' * indent + msg, kwargs
```
It is cleaner and friendlier to default the 'extra' argument to None
instead of either forcing the subclasses of LoggerAdapter to pass a None
value directly or to override the constructor.
This change is backward compatible because existing calls to
`LoggerAdapter.__init__` are already passing a value for the second
argument.
Automerge-Triggered-By: @vsajip
Fix a hang at fork in the logging module: the new private
_at_fork_reinit() method is now used to reinitialize locks at fork in
the child process.
The createLock() method is no longer used at fork.
This uses the heuristic of assuming a named tuple is a subclass of
tuple with a _fields attribute. This change means that contents of
a named tuple wouldn't be converted - if a user wants to have
ConvertingTuple functionality from a namedtuple, they will have to
implement it themselves.
This makes it easier to use a custom buffer when subclassing
MemoryHandler (by avoiding the explicity empty list literal
assignment in the flush method). For example, collection.deque
can now be used without any modifications to MemoryHandler.flush.
The same applies to BufferingHandler.
* bpo-37742: Return the root logger when logging.getLogger('root') is called.
* Added type check guard on logger name in logging.getLogger() and refined a test.
Fixed QueueListener in order to avoid random deadlocks.
Unable to add regression tests atm due to time constraints, will add it in a bit.
Regarding implementation, although it's nested, it does not cause performance issues whatsoever, and does not call task_done() in case of an exception (which is the right thing to do IMHO).
https://bugs.python.org/issue36813
Instead of attempting to acquire and release them all across fork
which was leading to deadlocks in some applications that had chained
their own handlers while holding multiple locks.
bpo-6721: When os.fork() was called while another thread holds a logging lock, the child process may deadlock when it tries to log. This fixes that by acquiring all logging locks before fork and releasing them afterwards.
A regression test that fails before this change is included.
Within the new unittest itself: There is a small _potential_ due to mixing of fork and a thread in the child process if the parent's thread happened to hold a non-reentrant library call lock (malloc?) when the os.fork() happens. buildbots and time will tell if this actually manifests itself in this test or not. :/ A functionality test that avoids that would be a challenge.
An alternate test that isn't trying to produce the deadlock itself but just checking that the release and acquire calls are made would be the next best alternative if so.
Jouke Witteveen
Michael P. Nitowski
Mario Corchero
Irit Katriel
Vinay Sajip
Kirill Pinchuk
Mariusz Felisiak
andrei kulakov
Yonatan Goldschmidt
Inada Naoki
Matthias Bussonnier
Victor Stinner
Necdet Can Atesman
Hansraj Das
Eric Larson
Irit Katriel
Bar Harel
Rémi Lapeyre
Arturo Escaip
l0rb
Derek Brown
Daniel Andersson
Lucas Cimon
Boris Feld
Riccardo Magliocchetti
Gregory P. Smith
Serhiy Storchaka
Rémi Lapeyre
Manjusaka
Josh Snyder
BNMetrics
Cheryl Sabella