-
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 function returned types #78
Conversation
Wow, this is great! I'll take a look. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall this looks like the right approach! Thank you.
I am curious though how the particular implementation might evolve as we add support for all the other opcodes as well.
I.e. I am thinking instead of storing the whole previous stack we might end up with just storing the opcode and some other structure?
But I think it's hard to know the scope of how general/specific it all should be until we add support for all other opcodes.
How would you feel about continue to work off this same branch on those? I think it's probably easiest to for me to continue reviewing it all as one big PR instead of merging in and then updating it.
record_api/infer_apis.py
Outdated
@@ -42,7 +42,7 @@ def __main__(): | |||
|
|||
|
|||
def parse_line( | |||
n: int, function: object, params=None, bound_params=None, | |||
n: int, function: object, params=None, bound_params=None, return_type=None |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is fine for now. We will have to add something to the signature to represent the return type and then we should display it as a return type annotation, see PEP 484:
def greeting(name: str) -> str:
return 'Hello ' + name
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It can be anything at the moment, as we don't have a specialised object. Do you mean to say adding Any
hint?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah for most opcodes we don't k ow the return type yet, but as you implement them, we will...
The whole "how do we type things and then combine them" is another part of the code, totally separate from the recording.
We can use the ObjectOutput
for places we don't know the return type yet. It is the same as typing.Any
.
That is totally possible, I started with whole stack in case I need something else, currently I am only using the
That sounds good to me. 👍 |
Ah a couple other things to think about (don't need to worry about these now, but wanted to get them down now that I remember them):
|
297f6c1
to
cf8c27c
Compare
Wouldn't that halt the execution of the tracing anyways? |
Not necessarily, if it is caught and execution continues. |
Oh, I see what you mean. By the way I have added the tracing for normal (non method) function calls too. |
record_api/core.py
Outdated
*((kwargs,) if kwargs else ()), | ||
return_type=type(tos), | ||
) | ||
|
||
# special case subscr b/c we only check first arg, not both | ||
def op_BINARY_SUBSCR(self): | ||
self.process((self.TOS1,), op.getitem, (self.TOS1, self.TOS)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we record the return type for any of some these special methods as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think so.
add return type to signature
c09670e
to
0066ca7
Compare
I have included the tracing for all the functions, where it made sense to, here are notes for the ones that didn't make it
Let me know, if that doesn't makes sense. I have added the signature for the return types as well. TODO: Merge return types (Union of return types if a function returns more than one type) |
The test failure is due to this issue: #83 |
@aktech That list sounds right on, thank you so much for this! I'll work on fixing the CI. |
@saulshanabrook I have added the return types union as well. |
Thank you for working on this! Looks good. |
This is an attempt to implement #15 to record function return types.
It delays the call to
log_call
method and saves the arguments as an attribute (log_call_args
) of the Stack class. The Stack now has aprevious_stack
attribute to check it the previous stack opname wasCALL_METHOD
, so that delayed call tolog_call
can be executed with the known returned value.TODO:
STORE_ATTR
: doesn’t returns anything as it sets a valueDELETE_SUBSCR
: doesn’t returns anythingSTORE_SUBSCR
: doesn’t returns anythingBUILD_TUPLE_UNPACK
: will return tupleBUILD_LIST_UNPACK
: will always return listBUILD_SET_UNPACK
: will always return setBUILD_TUPLE_UNPACK_WITH_CALL
: will always return tupleCOMPARE_OP
: will always return booleannp.add(1, 1)
andnp.add(1, 1.2)
)