Suggested solution: Use a logger with DEBUG level. The user can then fully control what his/her program displays.
Hi , what is the current behavior that you are suggesting to change? I want to know the commands that are being used, the actual output and the expected output. I am going to refactor the Python client. Especially, DictObject may not exist in the new version of the client. So bug report should capture the incorrect behaviors and the suggested behaviors independent of the current implementation.
what is the current behavior that you are suggesting to change.
Consider print('x') like it is done here:
“x“ will be displayed in the standard output of my program each time a call is made to the above instruction. However, I do not want to show this message to the user of my program, which makes use of the python package `synapseclient`, and want instead to show another message, for example. The issue here is that I don’t have control over this print() (please let me know if I’m wrong as I’m new to python).
I want to know the commands that are being used
There is no command involved. I am using the synapse python client programmatically. The function that I am calling is:
the actual output and the expected output
The output of print('x') is “x“ being displayed in the standard output. The expected behavior is the ability to silence, for example, all messages generated by the synapse client.
Suggested solution: Do not use print() to log messages/errors. Instead, logger should be systematically used. Considering the above line of code, a first solution is to replace print() by logger.debug(). An even better solution is to return the message as a Synapse Exception object that the user can catch and process as desired.
I second this request.
In the short term, you can print the logging info to stderr by setting file=sys.stderr (default is file=sys.stdout) inside the print() function. This way, the logging info won’t mess up anything listening on stdout, and users can silence messages by redirecting to /dev/null, for instance.
In the long term, I agree with . I think a top-level verbosity argument (e.g. tied to a --verbose CLI option) would be very useful. The built-in logging module was designed for this purpose.