-
-
Notifications
You must be signed in to change notification settings - Fork 31.1k
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
pydocs fails for some C implemented classes #64403
Comments
In 3.4 pydoc fails for the TkappType and TkttType names in the _tkinter module. $ ./python -m pydoc _tkinter.TkappType
Traceback (most recent call last):
File "/home/serhiy/py/cpython/Lib/runpy.py", line 189, in _run_module_as_main
"__main__", mod_spec)
File "/home/serhiy/py/cpython/Lib/runpy.py", line 87, in _run_code
exec(code, run_globals)
File "/home/serhiy/py/cpython/Lib/pydoc.py", line 2593, in <module>
cli()
File "/home/serhiy/py/cpython/Lib/pydoc.py", line 2558, in cli
help.help(arg)
File "/home/serhiy/py/cpython/Lib/pydoc.py", line 1840, in help
elif request: doc(request, 'Help on %s:', output=self._output)
File "/home/serhiy/py/cpython/Lib/pydoc.py", line 1578, in doc
pager(render_doc(thing, title, forceload))
File "/home/serhiy/py/cpython/Lib/pydoc.py", line 1555, in render_doc
module = inspect.getmodule(object)
File "/home/serhiy/py/cpython/Lib/inspect.py", line 610, in getmodule
file = getabsfile(object, _filename)
File "/home/serhiy/py/cpython/Lib/inspect.py", line 593, in getabsfile
_filename = getsourcefile(object) or getfile(object)
File "/home/serhiy/py/cpython/Lib/inspect.py", line 569, in getsourcefile
filename = getfile(object)
File "/home/serhiy/py/cpython/Lib/inspect.py", line 519, in getfile
object = sys.modules.get(object.__module__)
AttributeError: __module__ And same for _tkinter.TkttType. This issue can be easy fixed for the _tkinter module, but general solution is needed, because pydoc in 3.4 still can be broken for third-party code. |
See issue bpo-20372 -- fix for the 'inspect.getfile' function. |
With issue bpo-20372 patch pydoc no longer raise an exception, but it also doesn't produce useful output. In 3.3 it prints more details. |
The problem not in pydoc or inspect itself. In Python 3.3 _tkinter.TkappType has the __module__ attribute: >>> import _tkinter
>>> _tkinter.TkappType.__module__
'builtins' Something was changed in 3.4 and builtin classes without dot in qualified name no longer have the __module__ attribute. |
_tkinter.TkappType.__flags__ is different. In 3.3: 0b1000001000000000000 The difference is Py_TPFLAGS_HEAPTYPE. This is the consequence of the change made in bpo-15721. |
I think we should add a check to ensure than heap types have the __module__ attribute. |
Here is a patch which adds a warning to PyType_FromSpec and PyType_FromSpecWithBases if type spec name doesn't contain module name. In conjunction with tkinter_typespecs.patch it should fix the issue. |
What type of warning is more preferable here? It will be emitted at import. E.g.: $ ./python -Wall
Python 3.5.0a1+ (default:28ba862036cc+, Feb 28 2015, 11:01:23)
[GCC 4.8.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import tkinter
_frozen_importlib:321: SyntaxWarning: builtin type tkapp has no the __module__ attribute
_frozen_importlib:321: SyntaxWarning: builtin type tktimertoken has no the __module__ attribute DeprecationWarning? RuntimeWarning? |
The case for RuntimeWarning: the object isn't necessarily *broken* as such (most things will still work), but pickling and some introspection features may not work properly. The case for DeprecationWarning: breaking picking and introspection is bad when the fix (setting __module__) is straightforward, so this should eventually become an AttributeError:
My own preference is for the latter - eventually making it a hard requirement to specify the module name properly. Even true builtins officially live in the builtins module: >>> str.__module__
'builtins' |
It also can be ImportWarning (warnings triggered during the process of importing a module (ignored by default)). |
ImportWarning is slightly different - it's aimed at issues that happen during the operation of the import machinery itself. This isn't that - it's a warning related to the extension module actually initialising itself, so it's akin to a warning issued due to the behaviour of top level module source code, rather than by the import system. |
New changeset a192cc5a63be by Serhiy Storchaka in branch '3.4': New changeset 3244142eeafb by Serhiy Storchaka in branch 'default': New changeset d6dff5a5290a by Serhiy Storchaka in branch 'default': |
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: