id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
35667	Switch  usage to skip_file_prefixes instead of stacklevel when it makes sense	Simon Charette	Luna	"In most of our usages of `warnings.warn` (and almost every usage that relates to deprecation warnings) we want them to be associated to the first out-of-as that's the most likely location that can be adjusted to avoid the warning.

In order to achieve this goal we've historically attempted to pass a fixed `stacklevel` to `warnings.warn` which can sometimes [https://github.com/django/django/blob/f16a9a556fb4225f9094048614f4fcec3db7e067/django/conf/__init__.py#L146-L153 be tricky] and [https://code.djangoproject.com/ticket/35666 error prone] depending on how nested and convoluted the user or third-party app offending call site might be. In other cases [https://github.com/django/django/commit/fbd16438f46bc2128926958ad24331da5d1b406f we've opted not to] provide a `stacklevel` at all as determining the offending call site under all circumstances is impossible.

Well it appears that this is a problem that Python 3.12 allows frameworks to address in a better way with [https://docs.python.org/3/library/warnings.html#warnings.warn the introduction of] `warnings.warn(skip_file_prefixes: tuple[str] | None)`. This new feature would allow us to ensure that the proper offending call site is referenced when emitting from a deeply nested call site where `stacklevel` is inappropriate.

Since this is a Python 3.12+ feature I'd suggest we introduce a `get_non_django_stacklevel() -> int` (better name welcome) function that could be used to pass to `warnings.warn(stacklevel)` until we drop support for Python 3.11."	Cleanup/optimization	assigned	Utilities	dev	Normal		deprecation stacklevel	Adam Johnson	Accepted	1	0	0	1	0	0