improvements for the logging package

[Mike C. Fletcher]

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