This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Support full stack trace extraction in warnings.
Type: enhancement Stage:
Components: Library (Lib) Versions: Python 3.10
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: xmorel
Priority: normal Keywords:

Created on 2021-03-17 09:39 by xmorel, last changed 2022-04-11 14:59 by admin.

Messages (1)
msg388914 - (view) Author: Xavier Morel (xmorel) * Date: 2021-03-17 09:39
When triggering warnings, it's possible to pass in a `stacklevel` in order to point to a more informative cause than the `warnings.warn` call. 

For instance `stacklevel=2` is a common one for DeprecationWarning in order to mark the call itself as deprecated in the caller's codebase.

The problem with this is that it's not transitive, so when a dependency triggers a warning it can be hard to know where that comes from in the codebase (at least without `-Werror` which can prevent reaching the interesting warning entirely), and whether this is an issue in the codebase (e.g. passing bytes where the library really works in terms of strings) or whether it would be possible to work around the warning by using some other API.

In that case, the ability to show a full stack trace from the `stacklevel` down is very useful to diagnose such issues.

Not quite sure how it would be managed though: I'd think this should be part of the warnings filter information, but the `stacklevel` currently isn't stored there, and it might be risky to extend the warnings filter with a 6th field).
Date User Action Args
2022-04-11 14:59:42adminsetgithub: 87693
2021-03-17 09:39:37xmorelcreate