Feature request: a mode to disallow calling prototype or beta features

[mruberry]

PyTorch classifies features/components/modules into one of three stability categories: prototype, beta and stable. See https://pytorch.org/blog/pytorch-feature-classification-changes/ for details. While stable features are subject to our BC-breaking policy, prototype and beta features are not. Programs may accidentally rely on unstable features, however, even when they don't want to update frequently. Providing a mode that prevents reliance on unstable prototype and beta features would help enforce our recommended practice.

cc @ezyang @gchanan @albanD

[NicolasHug]

Providing a mode that prevents reliance on unstable prototype and beta features would help enforce our recommended practice

In scikit-learn, prototype features are not available unless users explicitly ask for it. For example the IterativeImputer is unstable and has to be explicitly "requested"

# explicitly require this experimental feature
from sklearn.experimental import enable_iterative_imputer  # noqa
# now you can import normally from sklearn.impute
from sklearn.impute import IterativeImputer

Once it becomes stable, enable_iterative_imputer can become a no-op, or raise a warning telling users they don't need to call it anymore. Users don't need to update their code because IterativeImputer is accessible from sklearn.impute whether it's experimental or stable.

---

In torchvision things are different: we put all prototype features in torchvision.prototype, and we only release the prototype subpackage in the nightlies. That means users need to update their code once prototype features become stable.

[stas00]

And as I commented elsewhere if any of these modes emit warnings that this or that is experimental or deprecated, or anything else that has nothing to with the actual code that is being run at the moment the user should have a way to turn these warnings off. Usually having a designated env var perhaps for each category and perhaps one to rule them all would make the use more user friendly.

To remind the main issue with uncontrolled emission of warnings is that the amount of noise because so large that the user stops looking the log altogether and then missing critical warnings related to the current code execution.

The idea flow chart model in my mind is this:

event: a new warning emitted 
can act on it? 
-> yes -> act on the warning -> the warning disappears
-> no -> should be able to turn it off as it can't be acted upon and is just noise