-
Notifications
You must be signed in to change notification settings - Fork 1
Description
For functions that fail refactoring preconditions due to side-effects caused by calls to print() (IO operations), refactor each such call to tf.print(). Then, the function in question would not fail refactoring preconditions due to calls to print() (it may fail for other reasons).
Suggested by @ansariahmad.
Regression
The side-effect for print() is found here:
Lines 58 to 62 in 444af9e
| if (typeReference.equals(PRINT_FUNCTION_TYPE_REFERENCE)) { | |
| // found a call to the built-in print function, which has side effects. | |
| // add a pointer to a fake global variable representing a modification to the output stream. | |
| this.result.add(GLOBAL_OUTPUT_STREAM_POINTER_KEY); | |
| } |
However, I don't think this is where any changes would occur. Instead, we'd probably examine all of the found side-effects to see if they are due to print(). If they are, then we could try to proceed with the refactoring of print() to tf.print(). If there are other problems with the function, it probably doesn't make sense to do this transformation since the function fails the preconditions anyway.
Note that there may be differences in behavior between Python's print() and TensorFlow's tf.print(). So, we would probably want a developer option here to use tf.print() in place of print().
Note also that this should only apply to eager to graph execution transformations. For graph execution to eager, we still want to consider print() as side-effecting because replacing it with tf.print() would most likely violate semantics preservation.