remove randn? from torch.testing namespace
#61840
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Redo of #60859. [ghstack-poisoned]
💊 CI failures summary and remediationsAs of commit 37bbf88 (more details on the Dr. CI page and at hud.pytorch.org/pr/61840): 💚 💚 Looks good so far! There are no failures yet. 💚 💚 Preview docs built from this PR 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 to the (internal) Dr. CI Users group. |
This was referenced Jul 19, 2021
pmeier
requested review from
mruberry
and removed request for
albanD and
soulitzer
Redo of #60859. [ghstack-poisoned]
mruberry
reviewed
Jul 21, 2021
|
There is only one appearance of "from torch.testing import randn_like" in test_autograd.py and no appearances of "from torch.testing import rand_like" within Facebook. "torch.testing.randn_like" appears in test_autograd.py and gradcheck.py, while "torch.testing.rand_like" never appears. In addition to these, "make_non_contiguous" is imported by only one project outside PyTorch. It is used in test_torch.py and gradcheck.py, though, so maybe that's a good candidate for a follow-up PR? "FileCheck" is used by several projects within Facebook, so that will require a focused follow-up. "assert_allclose" is used by several projects OUTSIDE of Facebook, so that will require a proper deprecation (see comments on that PR -- seems like that deprecation should wait for a stable API to use as an alternative?) The remaining functions exposed here: pytorch/torch/testing/_core.py Line 14 in db11619 are all dtype getters, I think. Some of these dtype getters are used by external projects. "floating_types" and "integral_types" are both used by torchvision, for example, and "get_all_device_types" and "get_all_math_dtypes" are used by additional projects outside PyTorch. I think, however, that we can move all these to deprecated if someone tries to import them from testing and create internal versions of these functions. For torchvision we can just copy the functions they're using, and the few external projects can update themselves with a simple list of dtypes. Updating our internal test suite to use the internal versions of these operations will take some doing, however. A lot of our test suites are calling torch.testing.get_all_device_types(), for example. How does that sound, @pmeier? |
Seems like this PR is good to go then.
Yes, I'll do that one next in the stack. The usage in
Sounds good.
For reference: #61844. I'm against waiting that long for a deprecation for two reasons:
Agreed. The largest problem that I see is that the naming scheme is very confusing if one is not aware of the organic growth of dtypes over time. For example, I bet other libraries using pytorch/torch/testing/_core.py Lines 386 to 388 in 1ce3281
Should be a fairly easy substitution. Might be some busy work, but I don't expect any larger obstacles. |
pmeier
added a commit
to pmeier/pytorch
that referenced
this pull request
Jul 21, 2021
Redo of pytorch#60859. ghstack-source-id: 9ccf58d Pull Request resolved: pytorch#61840
Redo of #60859. [ghstack-poisoned]
mruberry
approved these changes
Jul 23, 2021
|
@mruberry has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator. |
pmeier
added a commit
that referenced
this pull request
Aug 19, 2021
Following #61840 (comment), this deprecates all the dtype getters publicly exposed in the `torch.testing` namespace. The reason for this twofold: 1. If someone is not familiar with the C++ dispatch macros PyTorch uses, the names are misleading. For example `torch.testing.floating_types()` will only give you `float32` and `float64` skipping `float16` and `bfloat16`. 2. The dtype getters provide very minimal functionality that can be easily emulated by downstream libraries. We thought about [providing an replacement](https://gist.github.com/pmeier/3dfd2e105842ad0de4505068a1a0270a), but ultimately decided against it. The major problem is BC: by keeping it, either the namespace is getting messy again after a new dtype is added or we need to somehow version the return values of the getters. [ghstack-poisoned]
pmeier
added a commit
that referenced
this pull request
Aug 19, 2021
Following #61840 (comment), this deprecates all the dtype getters publicly exposed in the `torch.testing` namespace. The reason for this twofold: 1. If someone is not familiar with the C++ dispatch macros PyTorch uses, the names are misleading. For example `torch.testing.floating_types()` will only give you `float32` and `float64` skipping `float16` and `bfloat16`. 2. The dtype getters provide very minimal functionality that can be easily emulated by downstream libraries. We thought about [providing an replacement](https://gist.github.com/pmeier/3dfd2e105842ad0de4505068a1a0270a), but ultimately decided against it. The major problem is BC: by keeping it, either the namespace is getting messy again after a new dtype is added or we need to somehow version the return values of the getters. [ghstack-poisoned]
pmeier
added a commit
that referenced
this pull request
Aug 24, 2021
…g` namespace" Following #61840 (comment), this deprecates all the dtype getters publicly exposed in the `torch.testing` namespace. The reason for this twofold: 1. If someone is not familiar with the C++ dispatch macros PyTorch uses, the names are misleading. For example `torch.testing.floating_types()` will only give you `float32` and `float64` skipping `float16` and `bfloat16`. 2. The dtype getters provide very minimal functionality that can be easily emulated by downstream libraries. We thought about [providing an replacement](https://gist.github.com/pmeier/3dfd2e105842ad0de4505068a1a0270a), but ultimately decided against it. The major problem is BC: by keeping it, either the namespace is getting messy again after a new dtype is added or we need to somehow version the return values of the getters. [ghstack-poisoned]
pmeier
added a commit
that referenced
this pull request
Aug 24, 2021
Following #61840 (comment), this deprecates all the dtype getters publicly exposed in the `torch.testing` namespace. The reason for this twofold: 1. If someone is not familiar with the C++ dispatch macros PyTorch uses, the names are misleading. For example `torch.testing.floating_types()` will only give you `float32` and `float64` skipping `float16` and `bfloat16`. 2. The dtype getters provide very minimal functionality that can be easily emulated by downstream libraries. We thought about [providing an replacement](https://gist.github.com/pmeier/3dfd2e105842ad0de4505068a1a0270a), but ultimately decided against it. The major problem is BC: by keeping it, either the namespace is getting messy again after a new dtype is added or we need to somehow version the return values of the getters. [ghstack-poisoned]
pmeier
added a commit
that referenced
this pull request
Aug 26, 2021
…g` namespace" Following #61840 (comment), this deprecates all the dtype getters publicly exposed in the `torch.testing` namespace. The reason for this twofold: 1. If someone is not familiar with the C++ dispatch macros PyTorch uses, the names are misleading. For example `torch.testing.floating_types()` will only give you `float32` and `float64` skipping `float16` and `bfloat16`. 2. The dtype getters provide very minimal functionality that can be easily emulated by downstream libraries. We thought about [providing an replacement](https://gist.github.com/pmeier/3dfd2e105842ad0de4505068a1a0270a), but ultimately decided against it. The major problem is BC: by keeping it, either the namespace is getting messy again after a new dtype is added or we need to somehow version the return values of the getters. [ghstack-poisoned]
pmeier
added a commit
that referenced
this pull request
Aug 26, 2021
Following #61840 (comment), this deprecates all the dtype getters publicly exposed in the `torch.testing` namespace. The reason for this twofold: 1. If someone is not familiar with the C++ dispatch macros PyTorch uses, the names are misleading. For example `torch.testing.floating_types()` will only give you `float32` and `float64` skipping `float16` and `bfloat16`. 2. The dtype getters provide very minimal functionality that can be easily emulated by downstream libraries. We thought about [providing an replacement](https://gist.github.com/pmeier/3dfd2e105842ad0de4505068a1a0270a), but ultimately decided against it. The major problem is BC: by keeping it, either the namespace is getting messy again after a new dtype is added or we need to somehow version the return values of the getters. [ghstack-poisoned]
pmeier
added a commit
that referenced
this pull request
Aug 26, 2021
…g` namespace" Following #61840 (comment), this deprecates all the dtype getters publicly exposed in the `torch.testing` namespace. The reason for this twofold: 1. If someone is not familiar with the C++ dispatch macros PyTorch uses, the names are misleading. For example `torch.testing.floating_types()` will only give you `float32` and `float64` skipping `float16` and `bfloat16`. 2. The dtype getters provide very minimal functionality that can be easily emulated by downstream libraries. We thought about [providing an replacement](https://gist.github.com/pmeier/3dfd2e105842ad0de4505068a1a0270a), but ultimately decided against it. The major problem is BC: by keeping it, either the namespace is getting messy again after a new dtype is added or we need to somehow version the return values of the getters. [ghstack-poisoned]
pmeier
added a commit
that referenced
this pull request
Aug 26, 2021
Following #61840 (comment), this deprecates all the dtype getters publicly exposed in the `torch.testing` namespace. The reason for this twofold: 1. If someone is not familiar with the C++ dispatch macros PyTorch uses, the names are misleading. For example `torch.testing.floating_types()` will only give you `float32` and `float64` skipping `float16` and `bfloat16`. 2. The dtype getters provide very minimal functionality that can be easily emulated by downstream libraries. We thought about [providing an replacement](https://gist.github.com/pmeier/3dfd2e105842ad0de4505068a1a0270a), but ultimately decided against it. The major problem is BC: by keeping it, either the namespace is getting messy again after a new dtype is added or we need to somehow version the return values of the getters. [ghstack-poisoned]
pmeier
added a commit
that referenced
this pull request
Aug 26, 2021
…g` namespace" Following #61840 (comment), this deprecates all the dtype getters publicly exposed in the `torch.testing` namespace. The reason for this twofold: 1. If someone is not familiar with the C++ dispatch macros PyTorch uses, the names are misleading. For example `torch.testing.floating_types()` will only give you `float32` and `float64` skipping `float16` and `bfloat16`. 2. The dtype getters provide very minimal functionality that can be easily emulated by downstream libraries. We thought about [providing an replacement](https://gist.github.com/pmeier/3dfd2e105842ad0de4505068a1a0270a), but ultimately decided against it. The major problem is BC: by keeping it, either the namespace is getting messy again after a new dtype is added or we need to somehow version the return values of the getters. [ghstack-poisoned]
pmeier
added a commit
that referenced
this pull request
Aug 26, 2021
Following #61840 (comment), this deprecates all the dtype getters publicly exposed in the `torch.testing` namespace. The reason for this twofold: 1. If someone is not familiar with the C++ dispatch macros PyTorch uses, the names are misleading. For example `torch.testing.floating_types()` will only give you `float32` and `float64` skipping `float16` and `bfloat16`. 2. The dtype getters provide very minimal functionality that can be easily emulated by downstream libraries. We thought about [providing an replacement](https://gist.github.com/pmeier/3dfd2e105842ad0de4505068a1a0270a), but ultimately decided against it. The major problem is BC: by keeping it, either the namespace is getting messy again after a new dtype is added or we need to somehow version the return values of the getters. [ghstack-poisoned]
pmeier
added a commit
that referenced
this pull request
Aug 26, 2021
…g` namespace" Following #61840 (comment), this deprecates all the dtype getters publicly exposed in the `torch.testing` namespace. The reason for this twofold: 1. If someone is not familiar with the C++ dispatch macros PyTorch uses, the names are misleading. For example `torch.testing.floating_types()` will only give you `float32` and `float64` skipping `float16` and `bfloat16`. 2. The dtype getters provide very minimal functionality that can be easily emulated by downstream libraries. We thought about [providing an replacement](https://gist.github.com/pmeier/3dfd2e105842ad0de4505068a1a0270a), but ultimately decided against it. The major problem is BC: by keeping it, either the namespace is getting messy again after a new dtype is added or we need to somehow version the return values of the getters. [ghstack-poisoned]
pmeier
added a commit
that referenced
this pull request
Aug 26, 2021
Following #61840 (comment), this deprecates all the dtype getters publicly exposed in the `torch.testing` namespace. The reason for this twofold: 1. If someone is not familiar with the C++ dispatch macros PyTorch uses, the names are misleading. For example `torch.testing.floating_types()` will only give you `float32` and `float64` skipping `float16` and `bfloat16`. 2. The dtype getters provide very minimal functionality that can be easily emulated by downstream libraries. We thought about [providing an replacement](https://gist.github.com/pmeier/3dfd2e105842ad0de4505068a1a0270a), but ultimately decided against it. The major problem is BC: by keeping it, either the namespace is getting messy again after a new dtype is added or we need to somehow version the return values of the getters. [ghstack-poisoned]
pmeier
added a commit
that referenced
this pull request
Sep 6, 2021
…g` namespace" Following #61840 (comment), this deprecates all the dtype getters publicly exposed in the `torch.testing` namespace. The reason for this twofold: 1. If someone is not familiar with the C++ dispatch macros PyTorch uses, the names are misleading. For example `torch.testing.floating_types()` will only give you `float32` and `float64` skipping `float16` and `bfloat16`. 2. The dtype getters provide very minimal functionality that can be easily emulated by downstream libraries. We thought about [providing an replacement](https://gist.github.com/pmeier/3dfd2e105842ad0de4505068a1a0270a), but ultimately decided against it. The major problem is BC: by keeping it, either the namespace is getting messy again after a new dtype is added or we need to somehow version the return values of the getters. Differential Revision: [D30662206](https://our.internmc.facebook.com/intern/diff/D30662206) [ghstack-poisoned]
pmeier
added a commit
that referenced
this pull request
Sep 6, 2021
Following #61840 (comment), this deprecates all the dtype getters publicly exposed in the `torch.testing` namespace. The reason for this twofold: 1. If someone is not familiar with the C++ dispatch macros PyTorch uses, the names are misleading. For example `torch.testing.floating_types()` will only give you `float32` and `float64` skipping `float16` and `bfloat16`. 2. The dtype getters provide very minimal functionality that can be easily emulated by downstream libraries. We thought about [providing an replacement](https://gist.github.com/pmeier/3dfd2e105842ad0de4505068a1a0270a), but ultimately decided against it. The major problem is BC: by keeping it, either the namespace is getting messy again after a new dtype is added or we need to somehow version the return values of the getters. Differential Revision: [D30662206](https://our.internmc.facebook.com/intern/diff/D30662206) [ghstack-poisoned]
pmeier
added a commit
that referenced
this pull request
Sep 6, 2021
…g` namespace" Following #61840 (comment), this deprecates all the dtype getters publicly exposed in the `torch.testing` namespace. The reason for this twofold: 1. If someone is not familiar with the C++ dispatch macros PyTorch uses, the names are misleading. For example `torch.testing.floating_types()` will only give you `float32` and `float64` skipping `float16` and `bfloat16`. 2. The dtype getters provide very minimal functionality that can be easily emulated by downstream libraries. We thought about [providing an replacement](https://gist.github.com/pmeier/3dfd2e105842ad0de4505068a1a0270a), but ultimately decided against it. The major problem is BC: by keeping it, either the namespace is getting messy again after a new dtype is added or we need to somehow version the return values of the getters. Differential Revision: [D30662206](https://our.internmc.facebook.com/intern/diff/D30662206) [ghstack-poisoned]
pmeier
added a commit
that referenced
this pull request
Sep 6, 2021
Following #61840 (comment), this deprecates all the dtype getters publicly exposed in the `torch.testing` namespace. The reason for this twofold: 1. If someone is not familiar with the C++ dispatch macros PyTorch uses, the names are misleading. For example `torch.testing.floating_types()` will only give you `float32` and `float64` skipping `float16` and `bfloat16`. 2. The dtype getters provide very minimal functionality that can be easily emulated by downstream libraries. We thought about [providing an replacement](https://gist.github.com/pmeier/3dfd2e105842ad0de4505068a1a0270a), but ultimately decided against it. The major problem is BC: by keeping it, either the namespace is getting messy again after a new dtype is added or we need to somehow version the return values of the getters. Differential Revision: [D30662206](https://our.internmc.facebook.com/intern/diff/D30662206) [ghstack-poisoned]
pmeier
added a commit
that referenced
this pull request
Sep 6, 2021
…g` namespace" Following #61840 (comment), this deprecates all the dtype getters publicly exposed in the `torch.testing` namespace. The reason for this twofold: 1. If someone is not familiar with the C++ dispatch macros PyTorch uses, the names are misleading. For example `torch.testing.floating_types()` will only give you `float32` and `float64` skipping `float16` and `bfloat16`. 2. The dtype getters provide very minimal functionality that can be easily emulated by downstream libraries. We thought about [providing an replacement](https://gist.github.com/pmeier/3dfd2e105842ad0de4505068a1a0270a), but ultimately decided against it. The major problem is BC: by keeping it, either the namespace is getting messy again after a new dtype is added or we need to somehow version the return values of the getters. Differential Revision: [D30662206](https://our.internmc.facebook.com/intern/diff/D30662206) [ghstack-poisoned]
pmeier
added a commit
that referenced
this pull request
Sep 6, 2021
Following #61840 (comment), this deprecates all the dtype getters publicly exposed in the `torch.testing` namespace. The reason for this twofold: 1. If someone is not familiar with the C++ dispatch macros PyTorch uses, the names are misleading. For example `torch.testing.floating_types()` will only give you `float32` and `float64` skipping `float16` and `bfloat16`. 2. The dtype getters provide very minimal functionality that can be easily emulated by downstream libraries. We thought about [providing an replacement](https://gist.github.com/pmeier/3dfd2e105842ad0de4505068a1a0270a), but ultimately decided against it. The major problem is BC: by keeping it, either the namespace is getting messy again after a new dtype is added or we need to somehow version the return values of the getters. Differential Revision: [D30662206](https://our.internmc.facebook.com/intern/diff/D30662206) [ghstack-poisoned]
facebook-github-bot
pushed a commit
that referenced
this pull request
Sep 7, 2021
Summary: Pull Request resolved: #63554 Following #61840 (comment), this deprecates all the dtype getters publicly exposed in the `torch.testing` namespace. The reason for this twofold: 1. If someone is not familiar with the C++ dispatch macros PyTorch uses, the names are misleading. For example `torch.testing.floating_types()` will only give you `float32` and `float64` skipping `float16` and `bfloat16`. 2. The dtype getters provide very minimal functionality that can be easily emulated by downstream libraries. We thought about [providing an replacement](https://gist.github.com/pmeier/3dfd2e105842ad0de4505068a1a0270a), but ultimately decided against it. The major problem is BC: by keeping it, either the namespace is getting messy again after a new dtype is added or we need to somehow version the return values of the getters. Test Plan: Imported from OSS Reviewed By: H-Huang Differential Revision: D30662206 Pulled By: mruberry fbshipit-source-id: a2bdb10ab02ae665df1b5b76e8afa9af043bbf56
jasperzhong
pushed a commit
to jasperzhong/swift
that referenced
this pull request
Nov 25, 2021
Redo of #60859. ghstack-source-id: dad2fc7 Pull Request resolved: pytorch/pytorch#61840
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Stack from ghstack:
assert_allclosecallsites in favor ofassert_close#61841 Deprecateassert_allclosein favor ofassert_closerandn?fromtorch.testingnamespace #61840 removerandn?fromtorch.testingnamespaceRedo of #60859.
Differential Revision: D29871017