[Python-Dev] Re: PEP 282 comments

[Guido van Rossum]

>   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/)