improvements for the logging package
skip at pobox.com
skip at pobox.com
Tue Sep 13 13:22:42 CEST 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
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
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.
More information about the Python-list