ConfigArgParse
ConfigArgParse copied to clipboard
bw2
`write_config_file` uses `print`
Code: https://github.com/bw2/ConfigArgParse/blob/master/configargparse.py#L569
A module should not use print to output information.
That's true. Still what do you advice? use logging.info or output nothing?
A module should not use
Why? Can you point to an explanation? Can you explain why you do not want this?
That's true. Still what do you advice? use logging.info or output nothing?
@ronhanson Yes, I guess logging would be appropriate for this use case.
A module should not use
Why? Can you point to an explanation? Can you explain why you do not want this?
@johann-petrak Certainly. Printing implicitly uses stdout (or whatever output stream is currently set) to output information. If your application uses stdout to interact with your user, it is very inconvenient when modules interfere with this communication. Logging, on the other hand, can be configured in several ways. You can completely disable information output from modules, only output relevant information (log level) or write to different files (depending on the source module). Hence, one could simply disable message logging for this module and user interaction would be fine.
Sorry I misinterpreted the original issue report to mean print should not used to output 'information' (data) to the config file, but of course you are right it should not be used to inform the user. Thanks!
If this action should produce a message (to logger.info) is probably a matter of taste, I would personally prefer no message at all.
Fact is logging strongly depends on a custom setup. Real question is : Do we strongly want something to be displayed?
- Shall we completely avoid stdout printing and remove such lines, but keep stderr only in case of bugs?
- Or shall we convert to logging.info? logging.debug? Shall we setup a logger with defaulted screen output?
I would rather printing completely as it seems not a good practice anyway, and logging adds more maybe unnecessary complexity.
@mhoff @johann-petrak any suggestion on what you prefer? PR also accepted :).
I think with a library like this, I personally would:
- avoid printing completely
- avoid logging as much as possible or preferably completely, definitely do not set up the logger to default to producing any output
- if everything is done as expected/document, it is done silently
- if something unexpected happens or an error occurs, a library-specific exception for that situation is thrown. This allows the caller to either let the exception bubble up or deal with it specifically if it can be handled
Yep, agree with you. So I would rather remove print and not change it to logging. No idea how much work is involved here, but simply removing some print statements and removing message string construct should be pretty quick.