improvements for the logging package

[skip at pobox.com]

    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