-
-
Notifications
You must be signed in to change notification settings - Fork 29.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
-W option cannot use non-standard categories #66733
Comments
warnings._processoptions is called very early, before site-packages are enabled. Because of this, using a non-standard 'category' will almost certainly fail with the message:
The -W option would be a lot more useful if it could actually match non-standard categories (it does, after all, pretend to support modulename.classname). I don't see any easy way of fixing this, other than initializing the warnings module later or matching category names with the given string (and getting rid of the import). |
How would this work? Would it auto-import the module? |
It already does auto-import, but it does it before site-packages are set up, meaning that it fails in any practical setup. See _getcategory(), called by _processoptions(): https://hg.python.org/cpython/file/b15c5a66213f/Lib/warnings.py#l148 |
Doing the initialization later is not really an option as there can be warnings in the parser so it has to be resolved very early on. I guess some form could be a possibility, but that's also tricky as subclass matching also still needs to work. I think we would need to see a patch on the proposed solution before considering its acceptance. Another option would to parse it twice: once early on for Python internals and then again later once site-packages and various other things have been set up. Once again I would need to look at a patch before making a decision on whether it's an acceptable solution. |
Wow, this was news to me and I just ran into it in python 2.7. Checked in Python 3 and it's still there:
I see no easy way to fix this. One way I thought about is to have hooks for importing of modules (called when a module is put into There is no way to raise an exception before it is imported anyway... |
There is a thread on StackOverflow related to this problem: https://stackoverflow.com/q/42495641/974555 The (currently only and accepted) answer proposes as a workaround to set the PYTHONPATH variable, as the contents of those apparently *are* already in sys.path at the time warnings._processoptions is called, unlike site-packages. So manually adding site-packages to the PYTHONPATH variable does circumvent this problem (tested in Python 3.7.1). |
Coming here from astropy/astropy#9832 (comment) Importing the named module during warning initialization is somewhat like code injection. And it may introduce unintended side-effects -- for example if this causes some 3rd party libraries to initialize too early? String matching on the class name of every class in the hierarchy is safer, as there is no 'expected' code execution. |
Updated affected versions as I ran into this on 3.9.7. |
This is still an issue in Python 3.11. |
Any plans to fix this? It seems like string matching on the warning class' |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: