• 3 Posts
  • 934 Comments
Joined 7 months ago
cake
Cake day: May 10th, 2025

help-circle








  • Yes (and I’m sorry for not having more time to study this but):

    logDateTime

    That thing should be automatically printed by the logger somehow (most of the time, timestamps and log levels are inside the logger itself). If it’s not, check the configuration of the logger. Anyway. logDateTime has got to go. IMHO a logger is a magical object that you don’t control. It’s the user of the application who should set the rules one way or the other, like:

    logger.info("qbittorrent listen port set to...

    IIRC the logger can be set from the command-line, which you don’t control anyway. It’s the same thing in C++ and with any library on the planet (trust me), someone sets up the logging system for you outside of the application (in the main function or on the command-line or with environment variables or in a library/DLL) and all you can do is call “log.debug()” or “log.warning()” and hope for the best. Some libraries have huge systems to handle logs (rotating logs, serial ports, files, network…) and you shouldn’t give yourself headaches while using those things. Think of a logger as a pre-configured system that does way more that you should and want to know.

    logger = logging.getLogger(…

    Put that outside of main, after the imports. You can prepend it with an underscore to show that it’s a “private or protected” object belonging to your module. If it’s in main, you can’t use it in the other functions. You should do something like:

    from qbittorrent import Client
    
    _logger = logging.getLogger(...)
    

    This way your logger is independent on whether you’re using it from the command line (with main) or not (with an import).

    QB_PASSWORD

    Same thing with all the QB_ variables IF they don’t change, you can put them globally for such a module, like _QB_PASSWORD = ... and use it everywhere if your module were to change in the future. But only if the variables are constants across the usage of the script.

    a40124291102d

    Last but not least, use argparse if you can, it’s a simple module to handle command-line arguments. I guess that the container ID can change, you can either detect it with the subprocess module, or write def get_current_forwarded_port(container_id = "a40124291102d"): or use argparse. Feel free to ask if argparse if too weird, but it’s the best module out there and it’s built-in.

    TL;DR:

    • change logFilePath, what if I don’t have a filesystem or a hard drive?
    • change logDateTime and “message”, what if I (the user of your script) want another format?
    • change qbConfigUrl to be configurable, what if I use your script on a weird custom Linux or a BSD, or macOS or Windows?

    Anyway, great job, writing weird stuff for my own needs is how I started coding. Have fun.


  • Make the logger a global variable. This may be the only case where its acceptable to be global. And remove the log function. You can call the logger directly.

    Also wrap the main code (after BEGIN SCRIPT) in a main function.

    Last but not least log everything to the standard output (logging should do that by default), or configure the path in main(), it’s cleaner. If you log to stdout, the shell can redirect the logs to any path like python script.py > mylogs.txt