-
Notifications
You must be signed in to change notification settings - Fork 21.3k
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
Add API for listing functions overridable by __torch_function__ #33791
Conversation
dbae475
to
73ada4a
Compare
@cpuhrsch I'm deferring this code review to you. @ngoldbaum let me know if there's anything specific you want me to look at. |
functions, however in practice this is not enough to write tests for all of | ||
these functions without laboriously and manually copying the signature of each | ||
function for each test. To ease this process, the | ||
``torch._overrides.get_testing_overrides`` function returns a dictionary mapping |
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.
I see in the test below you exercise the torch.mean function, but there are two overloads for torch.mean
torch.mean(input) → Tensor
and
torch.mean(input, dim, keepdim=False, out=None) → Tensor
How is the second one tests?
Further we have our own argparser, which means the Python signature of a given function might not accurately capture all capabilities.
How is this dealt with?
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.
mean
is a C++ kernel, so its handled via the C++ argument parsing, e.g.
pytorch/torch/csrc/utils/python_arg_parser.cpp
Lines 247 to 251 in b10761d
if (THPVariable_Check(obj)) { | |
if (check_has_torch_function(obj)) { | |
append_overloaded_arg(overloaded_args, obj); | |
} | |
return true; |
I don't think there's a direct test for both signatures in the override tests. In principle we could add it but I'm not sure if it would be worth the extra boilerplate.
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 looks great! I added a few nits and a general question, but afterwards I think this can be approved and landed even if just treated as a code refactor / abstraction.
73ada4a
to
c5f7ea3
Compare
Fixed the nits, thank you for the copyediting :) |
💊 CircleCI build failures summary and remediationsAs of commit c5f7ea3: None of the build failures appear to be your fault.
Detailed failure analysisOne may explore the probable reasons each build failed interactively on the Dr. CI website. 🚧 2 upstream failures recognized by patterns:These builds matched patterns, but were probably caused by upstream breakages:
This comment was automatically generated by Dr. CI (expand for details).Follow this link to opt-out of these comments for your Pull Requests.Please report bugs/suggestions on the GitHub issue tracker. This comment has been revised 1 time. |
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.
Looks good to me! I'll adopt this within pytorch/nestedtensor as soon as it lands for testing.
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.
@cpuhrsch has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.
Looks like pytorch_linux_xenial_py3_5_test starts to become flaky after this test.
https://app.circleci.com/jobs/github/pytorch/pytorch/4678835 |
@mrshenli the fix for that is to add |
Hey @ngoldbaum, thanks a lot for prompt reply.
That will be great! Please send the fix and I will stamp. Thanks!! |
@ngoldbaum BTW, do you know why it is flaky instead of fail consistently. Below is a passing run: https://app.circleci.com/jobs/github/pytorch/pytorch/4685311 |
I'm not sure but if I had to guess it's because of dict order randomization on Python3.5 and something else is clobbering those entries. I'm going to see if I can figure out exactly why right now... |
Hey @ngoldbaum, since we need to wait for 5-6 hours for the CI to pass before we can land the fix, do you mind if I revert this PR for now, and you can send in the resubmit together with the fix? |
Go ahead, sorry for the trouble! |
Thanks! No worries :) |
…rch#33791) Summary: Fixes pytorch#33182 This adds private API functions that developers of types that implement `__torch_function__` can use to ensure full coverage of the subset of the PyTorch API that can be overrided. I've refactored some of the code in the tests into a new `torch._overrides.get_overridable_functions` function. I've also changed `TENSOR_LIKE_TORCH_OVERRIDES` into `torch._overrides.get_testing_overrides` and `IGNORED_TORCH_FUNCTIONS` into `torch._overrides.get_ignored_functions`. Making these two static global variables in the tests into functions should allow rewriting their implementation to construct their return values instead of just statically defining the return value as is done here. Currently that is blocked on not being able to inspect function signatures of compiled kernels in PyTorch (see pytorch#28233). See the docs I've added for usage examples of these new functions. I also refactored the existing override tests to make use of these new functions, which should be a good forcing function to make sure they're kept up-to-date. Finally, while working on this I discovered that `TestTorchFunctionOverrides.test_mean` and `TestTorchFunctionOverrides.test_mm` weren't ever being run because they were getting clobbered by the other dynamically generated override tests. I fixed that by renaming the tests and then fixing the actual test code. I've verified that all the subclassing semantics is correct and that the updated test answers are correct. I'm happy to put the fixes to the existing tests in as a separate pull request if that would be easier to review. ping cpuhrsch since the feature request originally came from them. Pull Request resolved: pytorch#33791 Differential Revision: D20195053 Pulled By: cpuhrsch fbshipit-source-id: 1585f4e405f5223932b410eae03a288dc8eb627e
…n__" (#34240) Summary: This is a redo of #33791, which was reverted because it introduced a flaky test. The test was flaky and only flaky on Python3.5 because of dict order randomization. I've fixed the issue with tests clobbering each other in b539fec and removed the override tests for `torch.nn.functional.tanh` and `torch.nn.functional.sigmoid`, which are deprecated and shouldn't be overridable in e0d7402. I also verified that no more test clobbering is happening. Pull Request resolved: #34240 Differential Revision: D20252442 Pulled By: cpuhrsch fbshipit-source-id: 069568e342a41c90e1dc76cbf85ba4aed47f24be
Fixes #33182
This adds private API functions that developers of types that implement
__torch_function__
can use to ensure full coverage of the subset of the PyTorch API that can be overrided.I've refactored some of the code in the tests into a new
torch._overrides.get_overridable_functions
function. I've also changedTENSOR_LIKE_TORCH_OVERRIDES
intotorch._overrides.get_testing_overrides
andIGNORED_TORCH_FUNCTIONS
intotorch._overrides.get_ignored_functions
. Making these two static global variables in the tests into functions should allow rewriting their implementation to construct their return values instead of just statically defining the return value as is done here. Currently that is blocked on not being able to inspect function signatures of compiled kernels in PyTorch (see #28233). See the docs I've added for usage examples of these new functions. I also refactored the existing override tests to make use of these new functions, which should be a good forcing function to make sure they're kept up-to-date.Finally, while working on this I discovered that
TestTorchFunctionOverrides.test_mean
andTestTorchFunctionOverrides.test_mm
weren't ever being run because they were getting clobbered by the other dynamically generated override tests. I fixed that by renaming the tests and then fixing the actual test code. I've verified that all the subclassing semantics is correct and that the updated test answers are correct. I'm happy to put the fixes to the existing tests in as a separate pull request if that would be easier to review.ping @cpuhrsch since the feature request originally came from them.