improvements for the logging package
Mike C. Fletcher
mcfletch at rogers.com
Tue Sep 13 17:52:13 CEST 2005
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 C. Fletcher
Designer, VR Plumber, Coder
More information about the Python-list