Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > improvements for the logging package

Reply
Thread Tools

improvements for the logging package

 
 
Vinay Sajip
Guest
Posts: n/a
 
      09-12-2005
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:

> >> - 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.


Could you please elaborate on this point further? What sort of
problems?

> 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.


OK, it's not right at the top of the docs, but the example at

http://docs.python.org/lib/minimal-example.html

has been there for a while, and if you think it can be made clearer,
please suggest how.

> If logging isn't trivial to use, then many simple apps won't use logging.


I would contend that it *is* pretty trivial to use for simple use
cases.

> Consequently, when they grow, logging has to be retrofitted.
>
> 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.


Not directly - but I work all the time with Python, Java, C, C++, C#,
JavaScript environments, among others. In some environments, such as
Java, CamelCase is more or less mandated. So I tend to use
camelCaseMethodNames because then I don't have a cognitive
disconnection every time I switch languages; I don't have the freedom
to use lower_case_with_underscores everywhere. I certainly didn't copy
much beyond the ideas from log4j - if you compare the log4j
implementation with stdlib logging, you will see how Pythonic it is in
comparison (if you leave aside superficial things like the use of
camelCaseMethodNames). In any event, the commonest use of logging does
not require you to use much camelCasing - apart from basicConfig()
which is only called once.

Regards,

Vinay

 
Reply With Quote
 
 
 
 
Vinay Sajip
Guest
Posts: n/a
 
      09-12-2005
Trent Mick wrote:

> Yah. It was added before Guido more clearly stated that he thought
> modules should have a successful life outside the core before being
> accepted in the stdlib.


Perhaps so, but Guido was also quite keen to get PEP-282 implemented
for inclusion in 2.3, and pronounced on the code that I put forward for
inclusion. The original code was all in one module - I partitioned it
into a package with subpackages as part of the review process conducted
on python-dev, in which Guido and several others took an active part.

I'm not sure that there really is a problem here, other than naming
convention. Since it's not practical to turn the clock back, my vote
would be to just live with it. I'd rather focus my energies on
functional improvements such as better configuration, etc. Not that I
get as much time as I'd like to work on improvements to logging - but
we've probably all been in an analogous position

Regards,

Vinay

 
Reply With Quote
 
 
 
 
Vinay Sajip
Guest
Posts: n/a
 
      09-12-2005
(E-Mail Removed) wrote:

> 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?


Well, it seems a little too late now, for unittest, threading, logging
and probably a few more.

> 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.


The breakage in my own usage of the module, and that of some existing
users of the logging module in its pre-stdlib days, seemed to me to be
good enough reason to leave the naming alone. Certainly, I was aware
that the stdlib at that time contained both naming styles. Certainly
the package did not have a long and stable life before coming into
stdlib, but neither was it written from scratch for inclusion in the
core.

What would you suggest for threading, unittest etc. in terms of binding
more unix_like_names and deprecating existing ones? It seems a lot of
work for not very much benefit, beyond consistency for its own sake.

> 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.


Not quite - as I said earlier, it was already pretty much written when
PEP-282 came along, and Trent very kindly let me piggyback onto it. Of
course, I changed a few things to fit in with PEP-282, and Trent let me
become the co-author.

Regards,

Vinay

 
Reply With Quote
 
Thomas Heller
Guest
Posts: n/a
 
      09-13-2005
"Vinay Sajip" <(E-Mail Removed)> writes:

> OK, it's not right at the top of the docs, but the example at
>
> http://docs.python.org/lib/minimal-example.html
>
> has been there for a while, and if you think it can be made clearer,
> please suggest how.


Maybe I'm missing something, but the code from the example doesn't work
for me:


>>> import logging
>>>
>>> logging.basicConfig(level=logging.DEBUG,

.... format='%(asctime)s %(levelname)s %(message)s',
.... filename='/tmp/myapp.log',
.... filemode='w')
Traceback (most recent call last):
File "<stdin>", line 4, in ?
TypeError: basicConfig() takes no arguments (4 given)
>>>

 
Reply With Quote
 
Peter Otten
Guest
Posts: n/a
 
      09-13-2005
Thomas Heller wrote:

>> OK, it's not right at the top of the docs, but the example at
>>
>> http://docs.python.org/lib/minimal-example.html
>>
>> has been there for a while, and if you think it can be made clearer,
>> please suggest how.

>
> Maybe I'm missing something, but the code from the example doesn't work
> for me:
>
>
>>>> import logging
>>>>
>>>> logging.basicConfig(level=logging.DEBUG,

> ... format='%(asctime)s %(levelname)s %(message)s',
> ... filename='/tmp/myapp.log',
> ... filemode='w')
> Traceback (most recent call last):
> File "<stdin>", line 4, in ?
> TypeError: basicConfig() takes no arguments (4 given)
>>>>


Are you perhaps trying to teach the 2.3 library a trick from the 2.4 docs?

Peter
 
Reply With Quote
 
Thomas Heller
Guest
Posts: n/a
 
      09-13-2005
Peter Otten <(E-Mail Removed)> writes:

> Thomas Heller wrote:
>
>>> OK, it's not right at the top of the docs, but the example at
>>>
>>> http://docs.python.org/lib/minimal-example.html
>>>
>>> has been there for a while, and if you think it can be made clearer,
>>> please suggest how.

>>
>> Maybe I'm missing something, but the code from the example doesn't work
>> for me:
>>
>>
>>>>> import logging
>>>>>
>>>>> logging.basicConfig(level=logging.DEBUG,

>> ... format='%(asctime)s %(levelname)s %(message)s',
>> ... filename='/tmp/myapp.log',
>> ... filemode='w')
>> Traceback (most recent call last):
>> File "<stdin>", line 4, in ?
>> TypeError: basicConfig() takes no arguments (4 given)
>>>>>

>
> Are you perhaps trying to teach the 2.3 library a trick from the 2.4 docs?


Yes, it seems so. Although I would have expected the documentation to
inform me about incompatible changes in the api.

Thomas
 
Reply With Quote
 
skip@pobox.com
Guest
Posts: n/a
 
      09-13-2005

Vinay> Well, it seems a little too late now, for unittest, threading, logging
Vinay> and probably a few more.

Correct, as I indicated.

>> I realize I'm playing the devil's advocate here.... Still, a dual
>> naming scheme with the non-PEP-8 names deprecated should be possible.


Vinay> The breakage in my own usage of the module, and that of some
Vinay> existing users of the logging module in its pre-stdlib days,
Vinay> seemed to me to be good enough reason to leave the naming
Vinay> alone.

That's fine, but once your code works its way into the core, it effectively
serves a different master. Many people use code in the core as examples of
how to write Python.

As for renaming/deprecating, that mechanically seems pretty straightforward
to me:

def basic_config(...):
blah blah blah
basicConfig = basic_config

Then you go through the official deprecation process (pending deprecation in
2.N, deprecation in 2.N+1, remove it in 2.N+2).

Vinay> Certainly, I was aware that the stdlib at that time contained
Vinay> both naming styles. Certainly the package did not have a long and
Vinay> stable life before coming into stdlib, but neither was it written
Vinay> from scratch for inclusion in the core.

My apologies. I thought it was.

Vinay> What would you suggest for threading, unittest etc. in terms of
Vinay> binding more unix_like_names and deprecating existing ones? It
Vinay> seems a lot of work for not very much benefit, beyond consistency
Vinay> for its own sake.

No, while "consistency is the hobgoblin of little minds" I think we should
strive for consistency within the core code, simply because it tends to be
used as an informal educational tool. As for the others (and logging as
well, for that matter), maybe it's just been too long to make changes and
they should only be changed in Py3K.

Skip
 
Reply With Quote
 
Mike C. Fletcher
Guest
Posts: n/a
 
      09-13-2005
(E-Mail Removed) wrote:

> Vinay> Well, it seems a little too late now, for unittest, threading, logging
> Vinay> and probably a few more.
>
>Correct, as I indicated.
>
>

....

> Vinay> What would you suggest for threading, unittest etc. in terms of
> Vinay> binding more unix_like_names and deprecating existing ones? It
> Vinay> seems a lot of work for not very much benefit, beyond consistency
> Vinay> for its own sake.
>
>No, while "consistency is the hobgoblin of little minds" I think we should
>strive for consistency within the core code, simply because it tends to be
>used as an informal educational tool. As for the others (and logging as
>well, for that matter), maybe it's just been too long to make changes and
>they should only be changed in Py3K.
>
>

I would strongly support the assertion that changing the interfaces on
deployed modules just to match the style guide is not something that
should happen before Py3K (that is to say, it should not happen until we
simply don't care about being able to run old Python code, which is to
say, a very long time).

There's no reason whatsoever to break *every* piece of code that ever
used a service just to support consistency in naming. Especially when
you're dealing with these modules that are used in probably the majority
of projects it's just a *huge* make-work project to go removing the
original service (API). If someone really wants the newly-named
version, create a different entry-point (module) and allow them to use
that. See how popular the renamed version is as a stand-alone module
where the barrier to entry is copying it in (which is far less than
revising hundreds of projects to deal with a deprecation). If it flies,
consider adding it to the standard library and eventually deprecating
the current version.

Consistency in the standard library is good. We *should* strive for it
as we improve the library. But reworking elements in the standard
library *just* to support consistency, at the expense of complete API
incompatibility, just doesn't have a good cost/benefit ratio for the
*users* of Python. A note in the docstring and documentation noting the
inconsistency in naming due to historic factors would seem to be more
appropriate if we're worried about emulation by users.

Anyway, I realise Skip probably was using "in Py3K" in the "some
unimaginably far-off time" sense, but just in case he wasn't I felt I
should pipe up...
Mike

--
________________________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://www.vrplumber.com
http://blog.vrplumber.com

 
Reply With Quote
 
Vinay Sajip
Guest
Posts: n/a
 
      09-13-2005

Thomas Heller wrote:
> Yes, it seems so. Although I would have expected the documentation to
> inform me about incompatible changes in the api.


It does, in the "in-development" version of the documentation. Sorry it
was not in the 2.4 releases

http://www.python.org/dev/doc/devel/...l-example.html

Regards,

Vinay

 
Reply With Quote
 
Thomas Heller
Guest
Posts: n/a
 
      09-14-2005
"Vinay Sajip" <(E-Mail Removed)> writes:

> Thomas Heller wrote:
>> Yes, it seems so. Although I would have expected the documentation to
>> inform me about incompatible changes in the api.

>
> It does, in the "in-development" version of the documentation. Sorry it
> was not in the 2.4 releases
>


Maybe it can be backported to 2.4.2 - is there still time for that?

Thomas
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Column: Wireless Networking Improvements in Windows XP Service Pac =?Utf-8?B?S2F0aGllIFdlcm5lcg==?= Wireless Networking 6 02-26-2006 05:17 PM
Feedback improvements requested David HTML 4 11-29-2005 02:18 PM
Firefox improvements ? Keith (Southend) Firefox 16 05-20-2005 03:38 PM
Multiple-reader-one-writer (MROW) locking -- soliciting improvements Matthew Scott Python 0 05-06-2005 04:01 AM
Improvements on Outlook Express 5.0 osmium Computer Support 1 01-13-2004 08:23 PM



Advertisments