Closed toni-neurosc closed 2 months ago
Hi Timon, glad you liked the change. Regarding the logging to a file, there's different ways to do it:
logger.set_debug_logfile(state: bool)
or maybe a @property
attributeAlso probably the logfile name should include datetime data too.
Will look into the formatting thing
@toni-neurosc Thanks again for improving the logger. I added the minor call to your log_to_file function which worked perfectly out of the box. I think having the call in the run function is a good place since it's the first time when output paths get specified. Feel free to merge if you agree with the changes.
Sure, having the logs in the data output folder is a good idea. I changed the directory creation to Path.mkdir (a bit less verbose) and fixed the decimal point issue. It turns out that the logger
class uses it's own C-style formatting style.
logger.info("%.2f seconds of data processed", feature_series['time'] / 1000)
It uses the same exact syntax as C's printf so I'm pretty used to it by now xD
I'm merging it now as it is, the logger can get more features in the future but I think for now we've done enough.
So I liked a lot the idea of using the logging library to replace prints, but the way it was implemented it was not taking full advantage of the logging system so I created a new module called nm_logger with a logger class inheriting from the original logging.Logger class with some tunable defaults and extra methods.
This way we can choose the defaults that are more reasonable for this software and also we can extend the functionality of our logging system at will modifying only this class.
Current defaults are log to console at "INFO" level. I also put a function to log to a file there as a demo of the things we can implement.
I got the general idea on how to structure the system from here, and created the logging class on top of it: https://dev.to/joaomcteixeira/setting-up-python-logging-for-a-library-app-6ml