В этом официальном руководстве объясняется, как перенести код TF 1 в TF 2 . Это, однако, не то, что я хочу. Я хочу, чтобы мой код работал нормально как на TF 1, так и на TF 2 (и я хочу только режим без усилий). Кроме того, я медленно хочу использовать некоторые из новых функций, но по желанию. (Например, пользователь может передать некоторую опцию, например --use-fancy-new-tf2-feature
, которая будет работать только с TF 2. Это нормально.) И, возможно, через один или два года я бы медленно отказался от поддержки TF 1. Но мне определенно нужен этот переходный период, когда поддерживаются обе версии TF.
Я не вижу ответа на этот вопрос в руководстве по миграции. Возможно, ответ заключается в том, что для этого просто нет «наилучшей практики». Хотя я думаю, что другие крупные проекты, вероятно, захотят сделать что-то подобное. Или, возможно, ответ заключается в том, что это будет слишком много усилий, и поэтому они просто будут мигрировать напрямую.
Я мог бы сделать что-то вроде этого:
try:
# https://www.tensorflow.org/guide/migrate
import tensorflow.compat.v1 as tf
tf.disable_v2_behavior()
except ImportError:
import tensorflow as tf
Однако, у этого есть некоторые недостатки :
- Мне нужно разместить этот фрагмент кода в каждом модуле, где я использую TF.
- Я мог бы поместить это в какой-то собственный модуль, например
tf_import.py
, а затем просто сделать from tf_import import tf
везде. Но это несколько уродливо.
- Это может усложнить код, который на самом деле хочет использовать какую-то новую функцию TF 2.
Я мог бы сделать что-то подобное :
try:
# https://www.tensorflow.org/guide/migrate
import tensorflow.compat.v1 as tf1
tf1.disable_v2_behavior()
import tensorflow as tf2
except ImportError:
import tensorflow as tf1
tf2 = None
Это может быть более чисто. Но я не уверен, что это путь к go. Или как другие люди делают это.
Кроме того, вместо того, чтобы звонить disable_v2_behavior
, я мог бы просто позвонить disable_eager_execution
. Но это может усложнить создание другого кода для совместимости как с TF 1, так и с TF 2.
(некоторые из этих мыслей я собираю в этой проблеме GitHub для нашего проекта RETURNN .)