[issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module

Nathaniel Smith added the comment: You're right, "impossible" is a slight exaggeration :-). As an alternative, every package could indeed carry around a table containing the details of importlib's call stack in every version of Python. (I also haven't checked whether it's consistent within a s

[issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module

Larry Hastings added the comment: If this has been broken since 3.3, I don't think it's a release blocker for 3.5. I'm willing to consider it a "bug" and accept a fix, but I'd prefer it to be as low-risk as possible (aka the Python version). Can someone fix the regressions? And, if the C fi

[issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module

Nathaniel Smith added the comment: > I still don't quite understand: what is the user-perceived result of this > change? Module authors issuing a DeprecationWarning can now use stacklevel=2 > instead of stacklevel=10? Exactly. There are a lot of deprecated modules in the wild, and the correct

[issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module

Larry Hastings added the comment: Is it really *impossible* to "correctly issue a deprecation warning for a module", as the title asserts? Or does the new import system simply make it *tiresome*? if sys.version_info.major == 3 and sys.version_info.minor == 4: stacklevel = 8 elif sys.versio

[issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module

Larry Hastings added the comment: The C implementation is making me nervous. My gut feeling is the Python implementation would be easier to get right. I still don't quite understand: what is the user-perceived result of this change? Module authors issuing a DeprecationWarning can now use sta

[issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module

Brett Cannon added the comment: Here is a patch that adds the C version of the frame skipping. Unfortunately it fails under test_threading, test_subprocess, test_multiprocessing_spawn. It's due to is_internal_frame() somehow although setting a breakpoint in gdb in that function never triggers.

[issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module

Changes by Josh Rosenberg : -- nosy: +josh.r ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module

Eric Snow added the comment: "Hybrid Nathaniel/Brett approach" LGTM -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubs

[issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module

Brett Cannon added the comment: Could someone do a quick code review of my latest patch? If the design looks sane I might be able to steal some time tomorrow to start on the C implementation. -- ___ Python tracker

[issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module

Brett Cannon added the comment: Here is an approach that somewhat merges Nathaniel's proposed solution and mine. -- Added file: http://bugs.python.org/file40211/issue24305.diff ___ Python tracker __

[issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module

Brett Cannon added the comment: Here is a new version of the patch with Nathaniel's and and Berker's comments addressed. -- Added file: http://bugs.python.org/file40199/issue24305.diff ___ Python tracker _

[issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module

Brett Cannon added the comment: Here is a pure Python patch that skips any frames that mentions 'importlib' and '_bootstrap' in the filename (it also skips _warnings.warn for easy testing since I didn't implement the C part). The only side-effect is that negative stack levels won't be the same

[issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module

Nathaniel Smith added the comment: Yeah, yours is probably better in fact, I was just trying to make the semantics as obvious as explicit as possible for a comment :-) -- ___ Python tracker ___

[issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module

Brett Cannon added the comment: Nathaniel's solution is basically what I came up with in issue #23810 except I simply skipped subtracting from the stack level if it was found to be an internal import frame instead of swapping in and out a callable. -- _

[issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module

Nathaniel Smith added the comment: For 3.4/3.5 purposes, I propose a simpler algorithm: first, define a function which takes a module name and returns true if it is part of the internal warning machinery and false otherwise. This is easy because we know what import machinery we ship. Then, to

[issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module

Brett Cannon added the comment: Will that be thread-safe? Plus storing that value in a way that _warnings and warnings can read will require something like a single-item list that can be mutated in-place. The other option is to teach warnings to skip anything coming from importlib/_bootstrap*

[issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module

Serhiy Storchaka added the comment: Frames can be skipped only for warnings issued by imported module code, not for warnings issued by import machinery itself. I propose following algorithm: Before executing module code push the current frame and the number of frames to skip in global stack i

[issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module

Changes by Brett Cannon : -- assignee: -> larry nosy: +larry ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: h

[issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module

Brett Cannon added the comment: I have merged over issue #23810 because they are aiming to solve the same problem and the conversation is split too much. Just thinking out loud, this situation is compounded by the fact that importlib itself has some warnings and so automatically stripping out

[issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module

Changes by Jakub Wilk : -- nosy: +jwilk ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org

[issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module

Nathaniel Smith added the comment: A nice new API is certainly a nice thing, but I feel that changing the stack walking code should be considered as fixing a regression introduced in 3.3. Indeed, searching github for code that actually uses the stacklevel= argument: https://github.com/sea

[issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module

Brett Cannon added the comment: Skipping select frames is a shift in semantics for warnings.warn() (so can't go into 3.5b1), doing it implicitly might be costly on interpreters where getting a frame is expensive, and coming up with a new API allows for a nicer design, e.g. `warnings.deprecate_

[issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module

Serhiy Storchaka added the comment: It would be better to skip _frozen_importlib frames automatically instead of forcing end users to use special API. -- nosy: +serhiy.storchaka ___ Python tracker

[issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module

Brett Cannon added the comment: My personal plan was to get issue #23810 finished, make sure it worked, and then expose a public API for declaring module deprecations which used the private API under the hood. I'm hoping to get #23810 done this Friday and then we can talk about how we may want

[issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module

Nick Coghlan added the comment: I've made this depend on issue 23810, rather than duplicating it. That way, issue 23810 can cover fixing the stdlib deprecation warnings, while this can cover making it a public API. -- dependencies: +Suboptimal stacklevel of deprecation warnings for for

[issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module

Berker Peksag added the comment: This looks like a duplicate of issue 23810 (there is a patch for stdlib usages, but it probably can be changed to a more general solution). -- nosy: +berker.peksag ___ Python tracker

[issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module

Changes by Barry A. Warsaw : -- nosy: +barry ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module

Nick Coghlan added the comment: Somewhat related issues are issue 16217 (traceback noise when running under python -m) and issue 23773 (traceback noise when running under custom import hooks) For 3.4 and 3.5, we may want to consider a brute force solution where the warnings module just straig

[issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module

Changes by Ned Deily : -- nosy: +brett.cannon, eric.snow, ncoghlan ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscrib

[issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module

Changes by Thomas Kluyver : -- nosy: +takluyver ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.py

[issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module

New submission from Nathaniel Smith: (Noticed while fixing the IPython equivalent of issue 24294) The obvious way to deprecate a module is to issue a DeprecationWarning inside the main body of the module, i.e. # thirdpartymodule.py import warnings warnings.warn("{} is deprecated".format(__name