-
Notifications
You must be signed in to change notification settings - Fork 17
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
Rethink async/isgenerator and alike. #301
Comments
Expanding a bit on this, to both try to get things out of my head, and take the habit of making longer description. Some of this information is likely necessary for rendering (like do you show In general we should try to keep information when we can, so that the frontend can decide what an how to render it. |
Do we have any cases of this? I could only find examples of "functions" throughout all the toml examples and the tests. |
In papyri itself, I don't think there are any in the tests. We should add those. |
Also adds a test for a generator function. Previously, different kinds of functions were not detected as the "function" condition was short-circuiting the cases. This is a first pass for allowing more details in this metadata. Addresses (but doesn't close) #301
right now, we store a
kind
to tell us wether something isbuiltins
,generator
...https://github.com/jupyter/papyri/blob/45c158d0e8011fe0bb23e6a5eb4a4b6e4e521245/papyri/signature.py#L90-L99C13
I'm not sure this is the best way as a builtin can be a coroutine function ... etc. It might be a good idea to rethink what we should store and how.
The text was updated successfully, but these errors were encountered: