Trent> Unfortunately your getting caught by the default logging level
Trent> being WARN, so that any log level below that is tossed.
Ah, okay. I'll pick back through the docs and see what I missed, then maybe
add a description of the minimal steps needed to get going.
>> I suspect the naming could be improved while providing backward
>> compatibility aliases and deprecating those names.
Trent> Do you mean naming like "makeLogRecord" etc?
Yes.
Trent> I thought PEP 8 said camelCase (or whatever it is called) was
Trent> okay?
Hmmm... In the section entitled "Naming Conventions" I see:
Function Names
Function names should be lowercase, possibly with words separated by
underscores to improve readability. mixedCase is allowed only in
contexts where that's already the prevailing style (e.g. threading.py),
to retain backwards compatibility.
Method Names and Instance Variables
The story is largely the same as with functions: in general, use
lowercase with words separated by underscores as necessary to improve
readability.
Since the logging package currently uses mixedCase it would appear it
shouldn't revert to lower_case. I'm thinking it should have probably used
lower_case from the start though. I see no real reason to have maintained
compatibility with log4j. Similarly, I think PyUnit (aka unittest) should
probably have used lower_case method/function names. After all, someone
went to the trouble of PEP-8-ing the module name when PyUnit got sucked into
the core. Why not the internals as well?
I realize I'm playing the devil's advocate here. If a module that's been
stable outside the core for awhile gets sucked into Python's inner orbit,
gratuitous breakage of the existing users' code should be frowned upon,
otherwise people will be hesitant to be early adopters. There's also the
matter of synchronizing multiple versions of the module (outside and inside
the core). Still, a dual naming scheme with the non-PEP-8 names deprecated
should be possible.
In the case of the logging module I'm not sure that applies. If I remember
correctly, it was more-or-less written for inclusion in the core. In that
case it should probably have adhered to PEP 8 from the start. Maybe going
forward we should be more adamant about that when an external module becomes
a candidate for inclusion in the core.
Skip
--
http://mail.python.org/mailman/listinfo/python-list
