New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TensorFlow 2.0 Preview - TypeError: 'Attribute' object is not iterable when using tf.function #25281
Comments
Actually we have hunted down the issue to the type annotations in the two losses. If we remove the return type we get |
@mr-ubik Is there any issue still or is it okay to be closed? Thanks! |
@jvishnuvardhan I guess you could close it, though the issue with type hints remains. |
This should be open. @alexbw we should support type annotations. With Py3 these will be increasingly pervasive and not supporting them will cause trouble. |
@mr-ubik we should at least say clearly that type annotations are not supported in autograph. Better, throw a meaningful error. A real fix may take longer. |
I agree that type annotations should not blow us up. Noted. Also, actually using type information will be important in the future, as it will help us catch "easy" cases when type information has been user-provided. We have avoided that strategy so far because we can't unambiguously determine type in all cases for Python, so focused on the purely runtime-type-discovery strategy. Adding even a little bit of ahead-of-time type information will help, and we'll get there. |
Thank you for the detailed investigation! Thankfully, this is a simpler bug in autograph and only incidentally caused by annotations (could have been any other field). We have a change in progress that will land over the next few days, and that should fix this particular error. We didn't run extensive tests with type-annotated code, which is why this bug slipped though (so there may be more), but I'm not aware of any reasons why annotations should not be supported, in the sense that autograph should just let them pass through. Anything that doesn't do that should be a bug, please let us know about it! Will update this thread as the fix lands. Cheers, |
Quick update - The TypeError has now been fixed, but a second fix is needed to make sure the symbols that the type annotations refer to resolve during the conversion process. The fix is largely a refactoring, and should land over the coming weeks - will post an update here. |
Just double checked this against tf-nightly and it runs. BTW, I had to make a few changes to get it to run well with tf.function, mainly in the train function. See below:
|
System information
tf-nightly-gpu-2.0-preview==2.0.0.dev20190129
AKA the latest nightlyDescribe the current behavior
Running the
train()
procedure provided below breaks while using the@tf.function
decorator.Describe the expected behavior
Not encountering any errors as per the "Effective TensorFlow 2.0 Guide"
Code to reproduce the issue
Other info / logs
Full Traceback
I had previously opened a question on SO.
EDIT: even writing a simpler input pipeline, dropping
tensorflow-datasets
and using the builtin Keras datasets the error persists.CC @galeone
The text was updated successfully, but these errors were encountered: