[issue45171] stacklevel handling in logging module is inconsistent
Change by Jouke Witteveen : -- pull_requests: +30220 pull_request: https://github.com/python/cpython/pull/32139 ___ Python tracker <https://bugs.python.org/issue45171> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45171] stacklevel handling in logging module is inconsistent
Jouke Witteveen added the comment: I would expect the opposite. Since the issue is visible only in certain cases (shortcut calls such as `logging.info` over `logger.info`, or redirected calls such as `logger.warn` which adds a stack frame for redirecting to `logger.warning`), any code that uses the stacklevel argument is probably broken in subtle ways. It will work fine for the anticipated case, but for instance behave weirdly in interactive sessions such as in a debugger. Added to this, if we want to fix the documentation instead of the logging module code, we have to come up with an understandable description of a behavior that is really inconsistent and odd. We would probably spend most of the documentation explaining edge cases. -- ___ Python tracker <https://bugs.python.org/issue45171> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45171] stacklevel handling in logging module is inconsistent
Change by Jouke Witteveen : -- keywords: +patch pull_requests: +26703 stage: -> patch review pull_request: https://github.com/python/cpython/pull/28287 ___ Python tracker <https://bugs.python.org/issue45171> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45171] stacklevel handling in logging module is inconsistent
New submission from Jouke Witteveen :
Handling of `stacklevel` in the logging module makes a few unwarranted
assumptions, for instance on the depth of the stack due to internal logging
module calls. This can be seen for instance when using the shortcut call
`logging.warning` to the root logger, instead of using `root_logger.warning`.
Consider the following `stacklevel.py` file:
```
import logging
import warnings
root_logger = logging.getLogger()
root_logger.handle = print
def test(**kwargs):
warnings.warn("warning-module", **kwargs)
logging.warning("on-module", **kwargs)
root_logger.warning("on-logger", **kwargs)
for stacklevel in range(5):
print(f"{stacklevel=}")
test(stacklevel=stacklevel)
```
The output of running `PYTHONWARNINGS=always python stacklevel.py` is:
```
stacklevel=0
stacklevel.py:8: UserWarning: warning-module
warnings.warn("warning-module", **kwargs)
stacklevel=1
stacklevel.py:8: UserWarning: warning-module
warnings.warn("warning-module", **kwargs)
stacklevel=2
stacklevel.py:14: UserWarning: warning-module
test(stacklevel=stacklevel)
stacklevel=3
sys:1: UserWarning: warning-module
stacklevel=4
sys:1: UserWarning: warning-module
```
Looking at the line numbers, we get:
stacklevel 0: lines 8, 9, 10.
stacklevel 1: lines 8, 9, 10.
stacklevel 2: lines 14, 9, 14.
stacklevel 3: lines sys:1, 14, 10.
stacklevel 4: lines sys:1, 9, 10.
As can be seen, the stacklevel for the on-module (shortcut) calls lags one
level of unwinding behind.
--
components: Library (Lib)
messages: 401638
nosy: joukewitteveen
priority: normal
severity: normal
status: open
title: stacklevel handling in logging module is inconsistent
versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue45171>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43956] C-API: Incorrect default value for Py_SetProgramName
Jouke Witteveen added the comment: It is unclear to me what is holding back the proposed pull request. Is it simply waiting for someone from docs@python to take a look, or did it fall off the radar of vstinner in his related activities to deprecate the legacy API? -- ___ Python tracker <https://bugs.python.org/issue43956> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15003] make PyNamespace_New() public
Change by Jouke Witteveen : -- nosy: +joukewitteveen ___ Python tracker <https://bugs.python.org/issue15003> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44113] [C API] Deprecate legacy API for configure Python initialization
Change by Jouke Witteveen : -- nosy: +joukewitteveen nosy_count: 2.0 -> 3.0 pull_requests: +24701 pull_request: https://github.com/python/cpython/pull/24876 ___ Python tracker <https://bugs.python.org/issue44113> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43956] C-API: Incorrect default value for Py_SetProgramName
New submission from Jouke Witteveen : The default program name is hardcoded in Python/initconfig.c:config_init_program_name. It is "python" on Windows, and "python3" elsewhere. The documentation currently suggests that it is "python" everywhere. Additionally, the documentation currently says: > The argument should point to a zero-terminated wide character string in > static storage whose contents will not change for the duration of the > program’s execution. The code, however, duplicates the string, so I am not sure this is true. -- assignee: docs@python components: Documentation messages: 392113 nosy: docs@python, joukewitteveen priority: normal pull_requests: 24356 severity: normal status: open title: C-API: Incorrect default value for Py_SetProgramName versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43956> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
