[EMAIL PROTECTED] 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 -- http://mail.python.org/mailman/listinfo/python-list
