Delete torch/__init__.pyi, deferring to direct extension stubs

[ezyang]

Stack from ghstack:

• Move all torch.nn.modules type annotations inline #38211 Move all torch.nn.modules type annotations inline
• Move torch/autograd/grad_mode.pyi stubs inline #38201 Move torch/autograd/grad_mode.pyi stubs inline
• Device and torch._C function cleanup #38173 Device and torch._C function cleanup
• Delete torch/__init__.pyi, deferring to direct extension stubs #38157 Delete torch/init.pyi, deferring to direct extension stubs

This removes the error prone process of assembling torch/__init__.pyi
(and frequently forgetting to expose things), since now we can simply
rely on the true source file to get things done. Most of the old
codegen in gen_pyi.py is now rerouted to various files:

• torch/_C/__init__.pyi (the dumping pile of all misc bindings)
• torch/_C/_nn.pyi (NN function bindings)
• torch/_C/_VariableFunctions.pyi (torch function bindings)

torch.types grew a bunch more definitions that previously where
defined in torch/__init__.pyi

Some miscellaneous changes

• Fixed a bug where we treat single TensorList argument as implying
  varargs are accepted. This is actually only supported on IntList.
  This means we can correctly generate a stub for dequantize.
• Add missing manual stub for nonzero
• Switched torch/onnx/operators.py to directly refer to _C module,
  since apparently mypy doesn't think that methods prefixed with
  underscores get reexported. This may be a recurring theme; maybe
  we need to find a better way to solve it.

Because I was really lazy, I dumped namedtuple definitions in both
torch._C and torch._C._VariableFunctions. This is definitely wrong.

Signed-off-by: Edward Z. Yang ezyang@fb.com

Differential Revision: D21497400

[dr-ci]

💊 CI failures summary and remediations

As of commit 6fac1e1 (more details on the Dr. CI page):

---

💚 💚 Looks good so far! There are no failures yet. 💚 💚

---

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.

See how this bot performed.

This comment has been revised 10 times.

[rgommers]

This is a little inconsistent compared with all the other underscored names above, one would expect _size to mean torch.size.

The generated _C/__init__.pyi now has a number of signatures with:

self, size: _size, *, dtype: _dtype=None, layout: _layout=strided, device: Union[_device, str, None]=None,

I think it would make sense to change _device above to _device: Union[torch.device, str, None] so the signatures become:

self, size: _size, *, dtype: _dtype=None, layout: _layout=strided, device: _device=None, ...

And if people need to use device rather than that union to annotate a device parameter, they can always use the explicit torch.device, the fully-qualified name should avoid mypy/issues/4146.

[ezyang]

One thing to note is that these names are all grandfathered from the old type stubs. So while I'm generally amenable to changing things up, it will greatly increase the surface area of the patch.

[rgommers]

Hmm, CI passed but I'm getting a number of errors locally like:

torch/_C/__init__.pyi:741: error: Incompatible default for argument "layout" (default has type "torch._C.layout", argument has type "torch.layout")  [assignment]

I'll do a full rebuild, maybe some codegen doesn't get triggered correctly on a partial rebuild.

[rgommers]

So this is not really a mypy bug, the issue is that torch.int exists and means torch.int32 rather than builtins.int. Given that torch.types cannot be used in the main torch namespace (have to avoid an import cycle), the better approach here would be that there's no shadowing in any other modules, so one can use plain int there.

[rgommers]

I think it's worth writing down the rules for what goes into torch.types, and making that a consistent design. Now for types._name, name can refer to a builtin, something in the torch namespace, or a useful Union defined inside types.

I'd lean towards being conservative for now, and only define unions here. The aliasing problem can be avoided by being careful in other files, and using fully-qualified names like torch.layout.

[rgommers]

@ezyang and I discussed offline: let's merge types.py as is, and worry about cleaning up the public API of that before the splitoff of the next release branch, to be able to move faster now and not make these initial PRs really large.

[facebook-github-bot]

@ezyang merged this pull request in 6edf340.

[facebook-github-bot]

@ezyang merged this pull request in 6edf340.