Keras: "Using X backend." always printed to stdout

Created on 5 Jan 2016  路  26Comments  路  Source: keras-team/keras

Im trying to use Keras in a setting where the output is piped to another application. However, in keras/backend/init.py the active backend in use is printed to stdout.

One solution would be to be able to configure keras not to print anything or alternatively print to stderr instead, e.g., print('Using TensorFlow backend.', file=sys.stderr).

Any fix would be appreciated.

Most helpful comment

Of course I can deal with this in multiple ways but I consider it bad behavior of a library to output random stuff to stdout at import time. Very inelegant...

All 26 comments

Im trying to use Keras in a setting where the output is piped to another application. However, in keras/backend/init.py the active backend in use is printed to stdout.

If you can't deal with that, you have bigger problems...

Of course I can deal with this in multiple ways but I consider it bad behavior of a library to output random stuff to stdout at import time. Very inelegant...

I'm running into this problem as well, it's not that it's impossible to work around. But it looks ugly and it shouldn't be needed.

import sys
stdout = sys.stdout
sys.stdout = open('/dev/null', 'w')
import keras
sys.stdout = stdout

This is the solution that I can come up with.

@fchollet what do you mean with "you have bigger problems"? Do you think that one shouldn't use stdout for piping data? That's how every unix application works. Or do you mean that there is an easy way to suppress the output? In that case, care to enlighten us?

Of course I can deal with this in multiple ways but I consider it bad behavior of a library to output random stuff to stdout at import time. Very inelegant...

Disagree. Its not random stuff. Keras never prints stuff that doesn't make sense..but libraries like theano does a lot. For e.g, if there is something wrong with your gpu setup and you import theano, you get a big chunk of C code and a huge error message, which is bigger than the buffer size of console. So like @fchollet said, if you cant deal with it, you have got bigger problems. As you said, there are multiple ways of working around it, but editing keras is at the bottom of the list.

So the reason it is okay for Keras to misbehave is that theano do in some cases? FYI, Tensorflow is well behaved and logs to stderr as expected. Also theano logs which device you are running on etc to stderr.

I Fully understand that this is not a big issue and is not a priority but given that the fix is so simple and obvious I don't understand the opposition.

@LinusU Haha

I'm running into this problem as well, it's not that it's impossible to work around. But it looks ugly and it shouldn't be e needed.

import sys
stdout = sys.stdout
sys.stdout = open('/dev/null', 'w')
import keras
sys.stdout = stdout

Some modification after their new release. Works on Windows as well.

stderr = sys.stderr
sys.stderr = open(os.devnull, 'w')
import keras
sys.stderr = stderr

Similar problem - additionally to "Using X backend" I always get the following output, messing up my progress bar:
2018-02-26 16:02:41.284721: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1120] Creating TensorFlow device (/device:GPU:0) -> (device: 0, name: GeForce GTX TITAN X, pci bus id: 0000:05:00.0, compute capability: 5.2)

Unfortunately, the suggestions with stderr and stdout from above did not help. Any other suggestions?

Is there any flag to disable output of Keras if it runs without errors?

Regardless of the libraries politeness policy, which is not too helpful, a solution might be to just comment out this line in your own cloned version of keras, in case you're using tensorflow.
https://github.com/keras-team/keras/blob/50411ccb0e7059ad2bd9286b64ffc2cda8957025/keras/backend/__init__.py#L86

@fchollet For the general discussion, it might be useful to comment out definitively just the tensorflow line, since it is defined as default backend here:
https://github.com/keras-team/keras/blob/50411ccb0e7059ad2bd9286b64ffc2cda8957025/keras/backend/__init__.py#L26

It makes sense to me to print info just when useful. Printing default configurations - something you can easily find in the docs - might be not useful. I want to be backed up by a feedback from the code just if I customize a feature, not if it behaves as default.

_Edit:_
If using Anaconda, keras/backend/__init__.py is located in:
C:\ProgramData\Anaconda3\envs\YOURENV\Lib\site-packages\keras\backend\__init__.py

Is this really fixed or should the title be changed to _"Using X backend." always printed to stderr_ and reopened?

This helps me:

#Suppress messages from tensorflow
stderr = sys.stderr
sys.stderr = open(os.devnull, 'w')
from keras.models import load_model
sys.stderr = stderr
os.environ['TF_CPP_MIN_LOG_LEVEL'] = '3'

Why not use the logging module?
Isn't this exactly what it is for?

I've just faced this issue when tried to use Keras in a system service on Windows. As you may guess there are no stdout and stderr in services, so I've got:

    sys.stderr.write('Using TensorFlow backend.\n')
AttributeError: 'NoneType' object has no attribute 'write' 

I'm gonna add fix for it.

None of the suggested fixes actually address the issue; they simply blind you to stderr. Using print is a silly thing to insist on, and keras should use the logging module.

I've found a bit cleaner workaround:

from contextlib import redirect_stderr
import os

with redirect_stderr(open(os.devnull, "w")):
    import keras

In my opinion no information about backend should be printed if backend is stated explicitly, i. e. via environmental variable or even with something like that

_BACKEND = 'tensorflow'
import keras

(the second one could be bad, but i don't know, for me it's quite reasonable).

No, the backend initialization code just shouldn't run on import. It's a bad practice.

Import should be lightweight and idempotent. Initialization should be done explicitly.

Instead of using: from keras import XY
Use: from tensorflow.keras import XY
This will remove the warning. Worked for me reference: https://pythonprogramming.net/introduction-deep-learning-python-tensorflow-keras/

You will use Keras that is built in TensorFlow, which has nothing (except interface) in common with this Keras. And it will be only possible to use TensorFlow as backend.
So it can't be considered as workaround.

Not only should it not bark if you specify all defaults, it should do its barking via the logging module so its output can be correctly handled by other processes. This is standard design in python - there's nothing stopping Keras from spitting out its messages all over stdout by default while giving us the ability to redirect those messages to a file or /dev/null (or, you know, set our logging level to what WE want...)

Just adding my voice to the discussion too - this is not acceptable for Keras not to use logging for this and offer a hook for the end user to customize the log level. That's a critical responsibility of any installable library - your logging choices should not affect the user.

I actually have a use case where I package a CLI streaming application into a Docker container. A separate batch job pulls this container and then invokes a workload that interacts with it via stdout, stdin and stderr from the container. Any log lines emitted to stdout or stderr have to be explicitly accounted for in this program, so it adds very annoying overhead chore for my stakeholder to write extra logic (and extra tests) to ensure they properly filter out all the extra chatter from Keras, when really since it is our application, shouldn't _we_ be in control of what is allowed to appear on stdout or stderr if the nature of our application is explicitly sensitive to this?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

kylemcdonald picture kylemcdonald  路  3Comments

somewacko picture somewacko  路  3Comments

zygmuntz picture zygmuntz  路  3Comments

farizrahman4u picture farizrahman4u  路  3Comments

LuCeHe picture LuCeHe  路  3Comments