Add tensorflow type stubs

[hmc-cs-mdrissi]

Summary

Motivated from this issue.

These are tensorflow stubs I've accumulated over year of writing tensorflow code and wanting to have APIs I rely on be type checked. They are very much incomplete with classes/functions included here being ones I've used. I normally rely on pylance to tell me which members/functions are untyped and add stubs as needed. Probably needs a lot of getattr fallbacks until the files become complete to avoid false positives.

The stubs follow documentation for imports and not source code. The stubs were written by running different inputs in repl + double checking with documentation.

I'm opening pr to start discussion on how to upstream them. If splitting into several prs is preferred I'm happy to do that.

I'd also ideally want to eventually move them to typeshed after I work out the issue of numpy dependency. The tensorflow stubs have a lot of functions that accept numpy arrays so I need to be able to import numpy in them. It may be wiser to prioritize typeshed issue vs upstream here and then migrate later. But there's also benefit that having them somewhere open source at least opens ability for others to fill them in gradually.

[ghost]

Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

❌ hmc-cs-mdrissi sign now
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[gramster]

Thanks for the PR; I would like to merge it but do need you to sign the CLA (there's a button higher up to do that). I think we need a mechanism like #pragma to allow us to map a type stub file to a file path in the package, so that things like docstring lookups and go-to-definition work; once we have that that we can look at bundling these. In the interim happy for these to have a home here (and if we can get to bundling them we should get good feedback plus contributions to make them more complete).

Can you clarify your comment about numpy? You should be able to import numpy, even if typeshed has no numpy stubs, as numpy is slowly adding inline type annotations.

[hmc-cs-mdrissi]

Numpy comment was specific to typeshed CI they run type checkers to examine correctness and currently assume only importing within same package or from other packages in typeshed. Since numpy isn't installed by default in there environment, it is main blocker on placing them in typeshed. I don't see any similar CI error here so shouldn't affect adding them.

For pragma question would it be better if I had the stubs define class in original place and then re-export them from documented place? Using tf.data.Dataset as an example I could have a stub file

tensorflow/python/data/ops/dataset_ops.pyi with definition of Dataset and then have second stub file.
tensorflow/data/__init__.pyi that just re-exports it. The latter file doesn't exist at runtime but it's intended way to import it.

Lastly for the CLA, it may take couple days as part of these stubs were made during work and I am asking my employer for permission. I am trying just looks like it's rare for people to ask for permission at my company.

[hmc-cs-mdrissi]

I've found process for CLA at my company. It will take a couple weeks though so will mark as draft.

[hmc-cs-mdrissi]

Sorry for forgetting about this. I'll close as main blocker on typeshed side to upstreaming is partly resolved (external type dependency support) and I'd prefer to maintain these in typeshed where all type checkers (pyright, mypy, pyre, pytype) can share these instead of being pylance specific.

[gramster]

That's great news. It's our preference that stubs go in typeshed too; this repo is more of a staging area for stubs that aren't ready to go there yet.