[Python-Dev] Re: PEP 282 comments (original) (raw)

Guido van Rossum guido@python.org
Fri, 22 Mar 2002 08:44:46 -0500

TM> The argument for the former is: TM> (1) KISS and YAGNI

[Jeremy]

I've said my piece for the most part, but this YAGNI stuff bugs me.

Then let me explain it some more. This logger module is not just for Zope, it's for all Python users. It's clear that for 99% of the uses, this is a case of YAGNI. Lots of standard Python modules lack advanced features so they can be more easy to understand or maintain. That's also the 80% principle, and I'm sticking to it.

In many of those cases, users who need an advanced feature can easily add it by creating a subclass, or using other extensibility features (e.g. hooks). Occasionally, it's needed to rewrite the base functionality from scratch in order to add something new. If that happens too often, the library design should probably be revised.

Zope is a sophisticated application that has needs that go far beyond those of most Python users. I'm very happy that it's proved possible to write Zope in Python. But I don't think it should be the measuring stick by which the functionality of the standard library must be measured.

Here's another way to look at it. To support the base functionality, we need an X amount of code. To add the feature of logging exceptions at any level, we would need an additional Y amount. The number Y is much smaller than X, but not insignificant. If the size of a subclass that adds that feature is approximately equal to Y, I think it should be kept out of the base class in this case, because you can easily write that subclass for Zope. If writing such a subclass would require significantly more code than Y (the amount of code needed to integrate it directly into the base class), I agree that the base class needs to be reworked to make this easier to add, or even to support it outright. But I find that hard to believe in this case.

[KISS]

As a compromise, would it make sense to have 5 simple logging methods that indicate the level by their name and have no support for handling exceptions, and one more general function that takes an error level argument and an optional exc_info? That more general function would be useful in some other cases (e.g. for programs that want to tweak the logging levels for certain loggable events) and adding it is much less disturbing to the simplicity of the standard interface than adding exc_info support to each of the simple methods.

It would mean that ZEO would have to use a slightly more expensive (because it's more general) interface in the one or two cases where it wants to log an exception at the info level. I doubt that these exceptions happen often enough to notice the difference.

--Guido van Rossum (home page: http://www.python.org/~guido/)