You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While I can see the thinking behind this setup, it causes a few issues that I think should be addressed.
The logger name is extremely complicated and overly specific. It depends not only on the log files being parsed, but also the exact paths given (so foo.log and ./foo.log will result in different loggers being setup for example). This makes it very difficult to access the logger via logging.getLogger(). For Logfile itself this isn't a problem because we always access the logger attribute on self directly, but it makes it difficult for other code to dynamically change the loglevel, for example.
The loglevel is always set in Logfile.__init__(). This means you can't change the loglevel before instantiating the Logfile object, even if you correctly predict the logger name ahead of time. If you're accessing the Logfile class directly this is fine because you can just pass in the loglevel, but if you're accessing some higher level function this is annoying.
Similar problem for the logger handler, you can't redirect the log to a file or something else unless you have a handle to the Logfile object.
I think it's fairly easy to refactor this, but it depends slightly on the intent behind setting up the logger this way. Firstly, would be good to understand why the parser type (ADF, Gaussian etc.) and the log file path(s) are used as the logger name. If it's just to include that information in each log message, then the Formatter would be the right place for this I think, or perhaps even better to use a custom log() method on Logfile (so we don't have to keep changing the Formatter).
If it's to get a unique logger for each parsed log file then I would question if this is necessary, and if it is necessary then more should be done to ensure it's actually unique (use a random name or checksum or something). In that case we should also find some way to remove the logger once it's finished with, as currently that's leaking memory. In either case, the logger for each log file should inherit from the main cclib logger 'cclib.parser' or 'cclib.parser.UNIQUE' etc.
Happy to work on this once we've decided on the right direction.
The text was updated successfully, but these errors were encountered:
Currently, each
Logfile
object sets up it's own logging object:While I can see the thinking behind this setup, it causes a few issues that I think should be addressed.
The logger name is extremely complicated and overly specific. It depends not only on the log files being parsed, but also the exact paths given (so
foo.log
and./foo.log
will result in different loggers being setup for example). This makes it very difficult to access the logger vialogging.getLogger()
. ForLogfile
itself this isn't a problem because we always access thelogger
attribute on self directly, but it makes it difficult for other code to dynamically change the loglevel, for example.The loglevel is always set in
Logfile.__init__()
. This means you can't change the loglevel before instantiating theLogfile
object, even if you correctly predict the logger name ahead of time. If you're accessing theLogfile
class directly this is fine because you can just pass in theloglevel
, but if you're accessing some higher level function this is annoying.Similar problem for the logger handler, you can't redirect the log to a file or something else unless you have a handle to the
Logfile
object.I think it's fairly easy to refactor this, but it depends slightly on the intent behind setting up the logger this way. Firstly, would be good to understand why the parser type (ADF, Gaussian etc.) and the log file path(s) are used as the logger name. If it's just to include that information in each log message, then the Formatter would be the right place for this I think, or perhaps even better to use a custom
log()
method onLogfile
(so we don't have to keep changing the Formatter).If it's to get a unique logger for each parsed log file then I would question if this is necessary, and if it is necessary then more should be done to ensure it's actually unique (use a random name or checksum or something). In that case we should also find some way to remove the logger once it's finished with, as currently that's leaking memory. In either case, the logger for each log file should inherit from the main cclib logger 'cclib.parser' or 'cclib.parser.UNIQUE' etc.
Happy to work on this once we've decided on the right direction.
The text was updated successfully, but these errors were encountered: