[issue46755] QueueHandler logs stack_info twice
New submission from Erik Montnemery :
logging.handlers.QueueHandler logs stack twice when stack_info=True:
>>> import logging
>>> from logging.handlers import QueueHandler, QueueListener
>>> from queue import Queue
>>> q = Queue()
>>> logging.getLogger().addHandler(QueueHandler(q))
>>> listener = QueueListener(q, logging.StreamHandler())
>>> listener.start()
>>> _LOGGER.error("Hello", stack_info=True)
Hello
Stack (most recent call last):
File "", line 1, in
Stack (most recent call last):
File "", line 1, in
Reproduced on CPython 3.9.9, but the code is unchanged in 3.10 and 3.11, so the
issue should exist there too.
Patching QueueHandler.prepare() to set stack_info to None seems to fix this:
diff --git a/Lib/logging/handlers.py b/Lib/logging/handlers.py
index d42c48de5f..7cd5646d85 100644
--- a/Lib/logging/handlers.py
+++ b/Lib/logging/handlers.py
@@ -1452,6 +1452,7 @@ def prepare(self, record):
record.args = None
record.exc_info = None
record.exc_text = None
+record.stack_info = None
return record
def emit(self, record):
Related issue: Issue34334, with patch
https://github.com/python/cpython/pull/9537
--
components: Library (Lib)
messages: 413278
nosy: erik.montnemery
priority: normal
severity: normal
status: open
title: QueueHandler logs stack_info twice
type: behavior
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue46755>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31084] QueueHandler not formatting messages
Change by Erik Montnemery : -- nosy: +emontnemery nosy_count: 2.0 -> 3.0 pull_requests: +29505 pull_request: https://github.com/python/cpython/pull/31355 ___ Python tracker <https://bugs.python.org/issue31084> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46755] QueueHandler logs stack_info twice
Change by Erik Montnemery : -- keywords: +patch nosy: +emontnemery nosy_count: 1.0 -> 2.0 pull_requests: +29504 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31355 ___ Python tracker <https://bugs.python.org/issue46755> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45972] typing.NamedTuple with default arguments without type annotations is falsy
New submission from Erik Montnemery : typing.NamedTuple behaves in surprising ways when it has default arguments which lack type annotations: >>> from typing import NamedTuple >>> class MyTuple(NamedTuple): ... a = 1000 ... >>> tmp = MyTuple() >>> tmp.a 1000 >>> len(tmp) 0 >>> bool(tmp) False Tested in Python 3.8 and 3.9 -- messages: 407570 nosy: emontnemery priority: normal severity: normal status: open title: typing.NamedTuple with default arguments without type annotations is falsy type: behavior versions: Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue45972> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45972] typing.NamedTuple with default arguments without type annotations is falsy
Erik Montnemery added the comment: I think elaborating in the documentation that only annotated attributes make it to the underlying namedtuple() would be helpful, it's not obvious that they are instead just class attributes. -- ___ Python tracker <https://bugs.python.org/issue45972> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45972] typing.NamedTuple with default arguments without type annotations is falsy
Erik Montnemery added the comment:
Maybe something like this:
diff --git a/Doc/library/typing.rst b/Doc/library/typing.rst
index 735d477db4..8de913d8db 100644
--- a/Doc/library/typing.rst
+++ b/Doc/library/typing.rst
@@ -1291,7 +1291,8 @@ These are not used in annotations. They are building
blocks for declaring types.
.. class:: NamedTuple
- Typed version of :func:`collections.namedtuple`.
+ Typed version of :func:`collections.namedtuple`, annotated fields are passed
+ to an underlying `collections.namedtuple`.
Usage::
@@ -1311,9 +1312,20 @@ These are not used in annotations. They are building
blocks for declaring types.
employee = Employee('Guido')
assert employee.id == 3
+ assert employee == ('Guido', 3)
Fields with a default value must come after any fields without a default.
+ Non-annotated fields will not be part of the `collections.namedtuple`::
+
+ class Employee(NamedTuple):
+ name = 'Guido'
+ id = 3
+
+ employee = Employee()
+ assert employee.id == 3
+ assert not employee # Passes because the collections.namedtuple is empty
+
The resulting class has an extra attribute ``__annotations__`` giving a
dict that maps the field names to the field types. (The field names are in
--
___
Python tracker
<https://bugs.python.org/issue45972>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
