It seems to me that logging.RotatingFileHandler should
have a way to spell "never delete old log files".  This
is useful in situations where you want an external
process (manual or automatic) make decisions about
deleting log files.

The problem with this is that on rollover, RotatingFileHandler renames old logs: rollover.log.3 -> rollover.log.4, rollover.log.2 -> rollover.log.3, rollover.log.1 -> rollover.log.2, rollover.log -> rollover.log.1, and a new rollover.log is opened. With an arbitrary number of old log files, this leads to arbitrary renaming time - which could cause long pauses due to logging, not a good idea.

If you are using e.g. logrotate or newsyslog, or a custom program to do logfile rotation, you can use the new logging.handlers.WatchedFileHandler handler (meant for use on Unix/Linux only - on Windows, logfiles can't be renamed or moved while in use and so the requirement doesn't arise) which watches the logged-to file to see when it changes. This has recently been checked into SVN trunk.

What about an optional different semantic for log renaming?  Rather than log -> log.1, log -> log.<count>+1, so if you have log, log.1, log.2; log -> log.3 and log gets created anew.

I've used a similar semantic in other logging packages, and it works pretty well.  It would also allow for users to have an "infinite" count of logfiles (if that is what they want).

Josiah - OK...suppose I use your semantics:

Create log ... at rollover,
log -> log.1, create log anew ... at rollover,
log -> log.2, create log anew ... at rollover,
log -> log.3, and the user has set a backup count of 3 so I can't do log -> log.4  - then I still need to rename files, it seems to me. If I don't, and say reuse log.1, then the user gets an unintuitive ordering where log.1 is newer than log.3 sometimes, but not ar other times - so your approach would *only* be beneficial where the backup count was infinite. For such scenarios, I think it's better to either use e.g. logrotate and WatchedFileHandler, or create a new class based on RotatingFileHandler to do what you want. Providing support for "infinite" log files is not a common enough use case, IMO, to justify support in the core package.

There are at least two ways to "solve" the "problem" regarding "what do we name the log after it is full".

Here are just a few:
1) The 'being written to' log is X.log, the most recent 'finished' log is X.log.<maxcount-1>, it uses the reverse renaming semantic to what is already available.
2) The 'being written to' log is X.log, the most recent 'finished' log is the log just before a 'missing' log.  Say you have .log, .log.1, .log.3; .log.1 is the most recent 'finished' log, and when .log is full, you delete .log.3, rename .log to .log.2, and start writing to a new .log ( (mod x) + 1 method ).

Semantic #1 isn't reasonable when you have a large number of log files (that isn't infinite), just like the current semantic isn't reasonable when you have a large number of log files (even infinite), but #2 is reasonable (in terms of filesystem manipulations) when you have any number of log files.  It is unambiguous to the computer, and can be made unambiguous to the user with a 'get log filenames' function that returns the chronological listing of log files (everything after the 'missing' file comes first, then the stuff before the 'missing' file, then the 'current' log).