>> - It's a package, but contrary to any other package I've ever seen,
>> most of its functionality is implemented in __init__.py.
Trent> I'm not defending the implementation, but does this cause any
Trent> particular problems?
No, it just seems symptomatic of some potential organizational problems.
>> import logging
>> logging.info('hello world')
>>
>> ought to just work (implicitly add a stream handler connected to
>> stderr to the root logger).
Trent> Maybe. Unless that causes troubles for real use.
Maybe there's a bug then (or maybe the docs still need work). When I
executed (all of these examples were typed at an interactive prompt):
import logging
logging.info('hello world')
I get no output. Looking at the doc for the basicConfig() function, I see:
The functions debug(), info(), warning(), error() and critical() will
call basicConfig() automatically if no handlers are defined for the root
logger.
If I read that right, my "hello world" example ought to work. I tried:
import logging
logging.getLogger("main")
logging.info("hello world")
and
import logging
logging.basicConfig()
logging.info("hello world")
and
import logging
logging.basicConfig()
log = logging.getLogger("main")
log.info("hello world")
Shouldn't one of these have emitted a "hello world" to stderr? (Maybe not.
Maybe I need to explicitly add handlers to non-root loggers.)
Trent> Having lazy configuration like this means that it can be a subtle
Trent> thing for top-level application code to setup the proper logging
Trent> configuration.
Again, based on my reading of the basicConfig doc, it seems like the logging
package is supposed to already do that.
Trent> I think the usability of the logging module could be much
Trent> improved with a nicer introduction to it (i.e. docs). It's not
Trent> really a "hello world" type of tool. Its usefulness only really
Trent> shows in larger use cases.
I agree about the docs. Whatever the "hello world" example is (I clearly
haven't figured it out yet), it ought to be right at the top of the docs.
If logging isn't trivial to use, then many simple apps won't use logging.
Consequently, when they grow, logging has to be retrofitted.
>> - Its functionality is partitioned in sometimes odd ways. For
>> example, it has a handlers module, but what I presume would be the
>> most commonly used handler (StreamHandler) is not defined there.
>>
>> - It doesn't use PEP 8 style as far as naming is concerned, instead
>> doing some sort of Java or C++ or Perl camelCase thing.
Trent> Perhaps Vijay (who did all the implementation) can comment on
Trent> these. Unfortunately backwards-compat might restrict some
Trent> cleanups to the package, but perhaps not too much. I did a poor
Trent> job of keeping up with the package after I laid out an initial
Trent> design, er copied an initial design from Java's log4j package
Trent> (and I'm not even a Java guy). :(
It was probably the log4j roots that provided the non-PEP 8 naming. I
suspect the naming could be improved while providing backward compatibility
aliases and deprecating those names.
--
http://mail.python.org/mailman/listinfo/python-list
