Python currently has 8.2 million active users worldwide. That’s almost a million more than Java, which was beating Python the prior year.
This new programming-language is changing the game with its unique user-friendly learning curve. Common in machine learning and IoT development, it’s no surprise it’s garnered such rapid adoption.
Developers and casual programmers alike are picking this language up, but what are the Python logging best practices?
If you work with Python, then keep reading. We’re going to dive into our Python logging guide so you can build a better understanding and practice of the logging module.
The Ultimate Python Logging Help
Python comes with a built-in logging module—one of the many things that give this programming-language its distinctive learning curve.
Utilizing this module is key to giving developers and others, supporting the application insight into their systems. Without it, there’s no real way to see what’s happening in the system or develop a way to fix it. An application’s status can flip in a second, going from operational to completely unusable. Logging shows you what and where the problem is so you can fix it.
This article will discuss aspects of two supporting features in the Python logging library: logging and handlers.
Logging is the process of denoting a specific entry with one of the six levels we’ll discuss below. Handlers process and store the log data once created so that the developer can access them later on.
Let’s start with breaking down the logging levels.
1. Logging Levels
Logging levels establish a tiered system of severity. They are also partnered with an integer, ranging from 0 – 50, to recognize its severity level. Below are the logging levels used in Python, ranking from least to most severe.
- NOTSET = 0
- DEBUG = 10
- INFO = 20
- WARNING = 30
- ERROR = 40
- CRITICAL = 50
Using logging levels isn’t only about measuring. It’s also about keeping uniformity and making the entries more manageable. When you log an entry, a handler can structure the log to follow a standard.
Then, when you need to reference back to a specific entry, you can see where it’s logged and access it instantly.
2. How to Use Them
Now it’s time to go over what the appropriate usages are for each log level.
NOTSET is the default logging level. This will cause all the different levels of logs to be printed or sent to the root logger.
DEBUG should be used for debugging purposes during development. It could be used to provide more information and help in diagnosing the problems. DEBUG offers more information to other people working on the same application.
INFO confirms things are working as expected. Use it when something interesting happens, but it happens as planned. For example, you’re starting a new project, and the development is working out well.
WARNING is for alerting developers something unexpected is happening, has happened, or may happen. This doesn’t necessarily mean a negative action occurred, but it does require attention.
ERROR is when things are starting to go south. Something has gone wrong and needs immediate attention, but the error can still be resolved. Examples include an API reporting the incorrect info.
CRITICAL should only be used when something drastic is wrong. This is the highest level of alert and requires absolute immediate attention, as the issue may not be resolvable. For instance, the application becomes entirely unusable.
Due to the module’s default setting, WARNING, ERROR, and CRITICAL will be logged automatically. It’s upon the developer’s discretion to use NOTSET, DEBUG, and INFO purposefully.
Utilizing these logging levels is crucial to the development of your understanding of the program.
The logging level defined above can be used as a top-level when defining the logging object as well as with handlers defined. Since we can define multiple handlers (file, stdout, stream, etc), each handler can define its own level to filter.
3. No New Methods
The provided logging essentials are the language’s standard method. A functioning method built to give developers an easy way to reduce noise, log, and store entries.
Do not attempt to write your own files, no matter how tempting.
Odds are they will not be as practical or useful as the practices provided. Applications can become noisy without proper logging methods, and what may work in the beginning can fail to keep up as the application grows. Sticking to the provided practices keeps you from experiencing these complications.
4. Timestamp Everything
Logging shows what’s happening, and timestamps show when.
Multiple developers will be working on the application, and using timestamps gives all parties involved a better understanding of the process taking place and makes troubleshooting easier. It also allows developers to analyze log entries and receive better insight into user behavior.
A good practice could involve defining a format for your logging object which can automatically contain information about the timestamp, line number, method name, etc.
The best Python logging methods and all language logging methods require the use of log rotation.
Log rotation is designed to automatically archive, compress, or delete old log files to prevent full disks. Thanks to Python’s excellent user experience, you don’t have to input this by hand. Instead, developers can use the RotatingFileHandler class, as opposed to the FileHandler one.
This can save you hours of work from editing old files by hand.
If you want to take it a step further, you can use the TimedRotatingFileHandler class. This allows you to capture logs via time intervals. Using this will create new log files every minute indefinitely.
You can personalize it even more by setting the log handler’s parameter to cap the number of log files.
Python Logging Best Practices: Time to Test Them Out!
Now that you’re brimming with all these Python logging best practices, it’s time to put them to the test.
The practices listed above are the best way to interact with the logging module. While implementing new ideas can be an exciting challenge, sticking to the proven methods keeps applications up and running long-term.
We hope this article was useful. Here at Apica, we want to help our fellow developers in any way that we can. If you have any further questions or want more information, don’t hesitate to contact us or check our blog for more insight!