-
Notifications
You must be signed in to change notification settings - Fork 6
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
Record return types and determine exposed modules for objects #15
Comments
We are currently looking at the Python bytecode stack to understand what operations are called, see:
I think for getting the return values of functions, we might have to basically wait till the next bytecode is executed and then look at the top value of the stack to see what was left there by the execution. |
This was merged in #78 but I had to revert that in #94 because it was causing segfaults.
and xarray:
We should re-try that branch locally with one of those to track down the segfault and fix it. |
Ah, I will take a look. |
One thing we should add is the ability to record the return type from a function.
This would help us understand the signatures better.
Also, it could help with another issue, which is that currently we output functions/classes from the modules they are defined in, not the module they are imported from.
We should instead try to output them where they are imported from. However, if multiple libraries import from different locations, we should choose one and have the others be aliases.
One way to do that would be to record the return types from the
getattr
calls, so if you did something likeimport numpy; numpy.arange
we would know the return type of the getattr is the arange function.We currently record those getattr, but don't have the return type.
If we did, we could infer that any getattr from a module, which returns a class/fn from a different module represents an import alias.
The text was updated successfully, but these errors were encountered: