-
-
Notifications
You must be signed in to change notification settings - Fork 30.7k
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
Use *.pyi stub files as source for the inspect.signature() #121945
Comments
CC @zooba |
This feature requires a lot of little details to get right, since |
Although pyi files are always guaranteed to parse as valid Python syntax, they often can't be imported at runtime since as @sobolevn says they support forward references in many contexts that runtime Python source files don't. The only way you'd be able to reliably retrieve information from them is by statically analysing their ASTs (which is what type checkers do). It's possible to figure out which AST node in a stub file corresponds to a given runtime symbol. https://github.com/JelleZijlstra/stubdefaulter and https://github.com/python/mypy/blob/master/mypy/stubtest.py are both examples of projects that compare AST nodes in parsed stub files to corresponding runtime objects. It's a pretty nontrivial task to do it correctly, however, and I'm not sure if it's something the standard library's |
Probably, so.
Yeah, I would expect that importing in runtime will be less trivial, but it's possible, isn't? Or did I miss something and there are cases, where above If that's true - this is a no-go for the idea (for me).
This is something I would like to avoid. I was thinking that possible objection against is using stub files for different goals, that are overlapping but... I.e. currently signatures of stdlib/builtins don't include typing info, hardly this will be changed. So, stubs shipped with CPython will be more simple. But it's NOT OK if Working with AST could be much more simple, if a decent part of data will be ignored. E.g. current inspect's helper, parsing Lines 2193 to 2337 in c8d2630
Most extensions, probably, aren't too complicated in this regard. For example, for most functions/classes in the gmpy2 introspection capabilities could be added with #101872. |
There might be, where generic types are used which are not really generic in runtime. It might be a rare case, but it might happen. # some.pyi
Alias = SomeFakeGeneric[int] There might be cases where
|
Yes, it is not possible to run stubs with a standard Python interpreter. I just tried with a few files in typeshed, and got the following problems:
This proposal doesn't say much about where the stub files should come from: should CPython ship them? If so, how do they interact with type checkers and with the stubs from typeshed? I maintain a project https://github.com/JelleZijlstra/typeshed_client that contains functionality for finding stub files, parsing them, and locating names. This could be used to create a "superpowered inspect.signature" that returns a signature as defined in the stub files. But it would be a lot of complexity to add to the standard library. |
@JelleZijlstra, thanks! For me, this kills the proposal:( I'll keep issue open for a while, maybe Steve could defend this idea. |
Feature or enhancement
Proposal:
In the referenced d.p.o thread it was proposed using stub files to get inspect.Signature's for extension modules.
Currently, there is no public interface to provide such data for introspection. There is only private, undocumented
__text_signature__
attribute, which parsed byinspect.signature()
. This interface also incomplete, e.g. it lacks support for return type annotations.Lets use stub files as a fallback for extension modules: if callable has no
__text_signature__
attribute - the inspect module should take look to stub files for the given module, import relevant stub object (with same import resolution ordering as for type checkers) and take it's signature. Later, the AC can be changed to generate stub files (or take them as input).PS: Maybe same approach could work to support functions with multiple signatures, if the
typing.get_overloads()
will fallback to stub files as well.If this does make sense, I'll provide a draft implementation.
Has this already been discussed elsewhere?
I have already discussed this feature proposal on Discourse
Links to previous discussion of this feature:
https://discuss.python.org/t/type-signatures-for-extension-modules-pep-draft/43914/22
The text was updated successfully, but these errors were encountered: