Skip to content

Refactor uses of print() to tf.print() that cause side-effect errors #405

@khatchad

Description

@khatchad

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:

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.

Metadata

Metadata

Assignees

Labels

enhancementNew feature or requestjavaPull requests that update Java codepreconditionsRefactoring preconditions need to be added.questionFurther information is requestedside-effects

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions