improvements for the logging package

[Vinay Sajip]

skip at pobox.com 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