Make RotatingFileHandler pad numbers with leading zeros

[bjhend]

Feature or enhancement

Proposal:

logging.handlers.RotatingFileHandler appends a number to a log file when performing the rotation. These numbers do not contain any leading zeros even if RotatingFileHandler is configured to create 10 or more backups, i.e. with backupCount set to 10 or bigger.

Hence, the log files are not properly ordered when listed. For example, a section of the list might look like:

log.18
log.19
log.2
log.20
log.21

or even worse:

log.1
log.10
log.100
log.11
log.12

It would be nice if RotatingFileHandler would pad the numbers with leading zeros up to the number of digits in the init argument backupCount in order to create a chronologically sorted list of log files, such that the latter example would look like:

log.001
log.002
...
log.010
log.011
log.012
...
log.100

This would help when analyzing the log files, particularly when you do a manual binary search for messages in a big number of rotated log files.

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Links to previous discussion of this feature:

No response

[serhiy-storchaka]

That's what namer is for.

[bjhend]

Thanks for pointing me on the namer. It made it possible for me to create a solution for my problem.

However, I still think that the RotatingFileHandler should produce numbers with equal digit lengths for several reasons:

• I expect many people would prefer proper sorting of the logs for further analysis and processing
• Creating a namer for this requires unnecessary many string and regular expression operations, because the namer receives the name as a string. It would likely be more efficient to implement that within the RotatingFileHandler.
• Creating special namers based on a fixed length number would be easier if they need to work with the numbers

[serhiy-storchaka]

This would be a breaking change. log.1 will not be deleted by a version that generates log.001. Also, there will be an issue in your application if you change backupCount and log.01 will become log.001.

This is an application level issue, and it should be solved at the application level. There is a lever for this, use it. You can also override other methods if you need more control.

BTW, many file managers on Linux are smart enough to show log.2 before log.10.