Rob Galanakis :
Regarding that Windows domain, was the library itself doing IO to authenticate?

Well, it was getting the credentials (including domain) across the network.

Rob Galanakis :
In response to logging and re-raising: What I meant is, this is pointless (though not uncommon) code:

[example snipped]

I agree with that – no need to log and just “raise”.

Regarding that Windows domain, was the library itself doing IO to authenticate? As I should have said in the article, IO is a good thing to log, and is definitely one place you want to log more than just the exception cases, like you say. For example I always log everything I send/receive to/from several of the local services we run our tools against.

In response to logging and re-raising: What I meant is, this is pointless (though not uncommon) code:
try:
foo()
except Exception:
logger.error(...)
raise
If you have more than the naked ‘raise’ statement that raises the current exception (well whatever the precise technical description is for what it does), clearly there is a reason to log.

Rob Galanakis :
On point #1, I agree. But if you are using functional styles, and are minimizing your use of mutable state, I think you should have less need of logging (see next point).
Regarding logging in libraries (point #2) … The less state your library stores and/or mutates, the better, and if you’re not storing or mutating, you can generally get away with raising errors that convey the failed information and not having to log. b) Likewise, your library should have clear contracts where logging in the case of a failure and not raising is never acceptable.

I’m not sure that logging should be tied to whether you store or mutate state. In the PPTP example I gave above, there was no storing or mutating of state: however, the client was passing an implicit Windows domain, which was causing authentication failure even though the username and password were correct. Now an authentication failure is not even an exception-raising condition: however, setting verbose logging allowed me to see what the problem was.

I would say that the usage of logging should be wider than just the exception cases (of course, based on the developer’s discretion).

On the question of logging and re-raising: I think it’s best to log and handle at one level if possible, but sometimes it’s not unreasonable to log at a low level and raise a conceptually higher-level exception which makes sense at the relevant level (for example, low level SQL exception is logged and a higher level ORM exception is raised. The logging of the SQL exception aids the ORM library developer – knowing why the ORM exception was raised – but the ORM-level exception aids the ORM user, because it is couched in ORM concepts).

Vinay, when you comment on logging it isn’t two cents, it is more like several dollars :) Glad you read the post and commented.

On point #1, I agree. But if you are using functional styles, and are minimizing your use of mutable state, I think you should have less need of logging (see next point).

Regarding logging in libraries (point #2), I suppose like many ‘best practices’ we establish, they are reactions against clearly bad practices and replacing them with the opposite is rarely the best thing. So the discouragement of logging in libraries comes down to two things: a) The less state your library stores and/or mutates, the better, and if you’re not storing or mutating, you can generally get away with raising errors that convey the failed information and not having to log. b) Likewise, your library should have clear contracts where logging in the case of a failure and not raising is never acceptable. But of course this is all relative and imperfect, and people should use their best judgement- if people are going to write crappy libraries, the advice about logging isn’t going to make it much better or worse.

1. Python does not force you to use OO, and for those people who use functional styles (or a mixture), using __name__ as the logger name is the best practice. Using the type(self).__name__ gives you the unqualified name of the class, which in a large system may occur in a number of different packages. Possibly ‘%s.%s’ % (type(self).__module__, type(self).__name__) is more useful, as it allows filtering of all classes in a module using just the module name.

2. Logging in libraries shouldn’t be discouraged. For example I was just looking at a problem with PPTP connections working to a server from one machine but not another. The PPTP protocol code handling is in a library, but luckily it uses logging, so I could see what was happening under the hood.

A library is meant to be used as a black box, but library developers are just like the rest of us in terms of not necessarily having thought of all corner cases. Faced with imperfect software, logging is one of the few ways you can look into a running system in production without bringing it down. That goes for both the application and its libraries.

Just my 2 cents.