Consider partial stubs for TensorFlow to work around lazy import issues

[gramster]

TF does a bunch of nasty stuff to implement lazy loading of modules, which means we don't pick up the imports when doing static analysis. We should see if we can use a partial stub that just uses (non-lazy) imports to work around this problem.

[hmc-cs-mdrissi]

Hmm, tf imports are a lot worse then that. Tensorflow uses a decorator to modify expected import paths at runtime heavily. Most tensorflow classes look like,

@tf_export("data.Dataset", v1=[])
class Dataset:
  ... 

And you import Dataset from tf.data even though it's actually defined in tf.python.data.ops.dataset_ops. tf.data folder doesn't even exist in source files. Recommending imports like tf.python.data.ops is a good way to have a lot of internal imports that are undocumented/may be unstable across versions.

My experience with tf stubs is manually creating stubs based on documentation and analyzing source it does too much import magic unless you want to teach tool to know how tf_export decorator behaves. I've tried generated stubs + adjustments before (both stubgen and pyright --createstub) and got too many false positives and gave up on them.

I have a decent amount of tf stubs but have procrastinated upstreaming them to typeshed (mostly need to figure out this first)

[gramster]

You could contribute them at https://github.com/microsoft/python-type-stubs in the interim; they may get fixes contributed there and we could bundle them.

…

On Wed, Aug 10, 2022 at 4:43 PM Mehdi Drissi ***@***.***> wrote: Hmm, tf imports are a lot worse then that. Tensorflow uses a decorator to modify expected import paths at runtime heavily. Most tensorflow classes look like <https://github.com/tensorflow/tensorflow/blob/d8ce9f9c301d021a69953134185ab728c1c248d3/tensorflow/python/data/ops/dataset_ops.py#L132> , @tf_export("data.Dataset", v1=[]) class Dataset: ... And you import Dataset from tf.data even though it's actually defined in tf.python.data.ops.dataset_ops. tf.data folder doesn't even exist in source files. Recommending imports like tf.python.data.ops is a good way to have a lot of internal imports that are undocumented/may be unstable across versions. My experience with tf stubs is manually creating stubs based on documentation and analyzing source it does too much import magic unless you want to teach tool to know how tf_export decorator behaves. I've tried generated stubs + adjustments before (both stubgen and pyright --createstub) and got too many false positives and gave up on them. I have a decent amount of tf stubs but have procrastinated upstreaming them to typeshed (mostly need to figure out this first <python/typeshed#5768>) — Reply to this email directly, view it on GitHub <#3174 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAVCPCFU7GKNXYYFQPJQCPTVYQ5A5ANCNFSM56GI3PZQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[hmc-cs-mdrissi]

Sure, I've made a pr with all my current tensorflow stubs. We can use that to discuss if those stubs are worth having there. It's a bit unclear to me on what place they should eventually live in, but somewhere open source that others can contribute is better then nowhere.

[Avasam]

@hmc-cs-mdrissi
typeshed is now very close to allowing non-types dependencies (there's a small issue with pytype left to fix, but pyright and stubtest work).

[hmc-cs-mdrissi]

Yes I'm happy to see your/Alex's work. I'll pick back up the tensorflow initial stubs pr this weekend and see if numpy errors are now all resolved.

[hmc-cs-mdrissi]

I think this can be closed. types-tensorflow now exists. It is very incomplete and will grow over time, but anyone is welcome to add more stubs to typeshed and I'll happily review them.