I'm a bit sad that I'm clearly on the loosing side of the argument. I now
believe that I must be grossly underestimating the amount of effort and
overestimating the potential gain. However, I still feel that we should
strive for consistency in the long run. I do not propose to do this at
once, but I feel that at least some collaborated effort would be nice. (If
not only for this kind of mail threads.)
If I would start an effort to - for instance - 'fix' some camelCased
modules, and attempt to make it 100% backwards compatible, including tests,
would there be any chance it could be merged at some point? Otherwise, I
feel it would be a totally pointless effort ;).
On Tue, 26 Jul 2016 at 18:29 Brett Cannon
On Mon, 25 Jul 2016 at 13:03 Mark Mollineaux
wrote: I've pined for this (and feel a real mental pain every time I use one of those poorlyCased names)-- I end up using a lot of mental space remembering exactly HOW each stdlib isn't consistent.
Aliasing consistent names in each case seems like a real win all around, personally.
For those that want consistent names, you could create a PyPI package that is nothing more than the aliased names as suggested.
Otherwise I get the desire for consistency, but as pointed out by a bunch of other core devs, we have thought about this many times and always reach the same conclusion that the amount of work and potential code breakage is too great.
-Brett
Hi python-ideas,
As you all know, the Python stdlib can sometimes be a bit of an inconsistent mess that can be surprising in how it names things. This is mostly caused by the fact that several modules were developed before the introduction of PEP-8, and now we're stuck with the older naming within these modules.
It has been said and discussed in the past [1][2] that the stdlib is in fact inconsistent, but fixing this has almost always been disregarded as being too painful (after all, we don't want a new Python 3 all over again). However, this way, we will never move away from these inconsistencies. Perhaps this is fine, but I think we should at least consider providing function and class names that are unsurprising for developers.
While maintaining full backwards compatibility, my idea is that we should offer consistently named aliases in -eventually- all stdlib modules. For instance, with Python 2.6, the threading module received this
unfortunately this was not expanded to all modules.
What am I speaking of precisely? I have done a quick survey of the stdlib and found the following examples. Please note, this is a highly opinionated list; some names may have been chosen with a very good reason, and others are just a matter of taste. Hopefully you agree with at least some of
On Mon, Jul 25, 2016 at 10:55 AM, Ralph Broenink
wrote: treatment, but them: * The CamelCasing in some modules are the most obvious culprits, e.g. logging and unittest. There is obviously an issue regarding subclasses
and
methods that are supposed to be overridden, but I feel we could make it work.
* All lower case class names, such as collections.defaultdict and collections.deque, should be CamelCased. Another example is datetime, which uses names such as timedelta instead of TimeDelta.
* Inconsistent names all together, such as re.sub, which I feel should be re.replace (cf. str.replace). But also re.finditer and re.findall, but no re.find.
* Names that do not reflect actual usage, such as ssl.PROTOCOL_SSLv23, which can in fact not be used as client for SSLv2.
* Underscore usage, such as tarfile.TarFile.gettarinfo (should it not be get_tar_info?), http.client.HTTPConnection.getresponse vs set_debuglevel, and pathlib.Path.samefile vs pathlib.Path.read_text. And is it pkgutil.iter_modules or is it pathlib.Path.iterdir (or re.finditer)?
* Usage of various abbreviations, such as in filecmp.cmp
* Inconsistencies between similar modules, e.g. between tarfile.TarFile.add and zipfile.ZipFile.write.
These are just some examples of inconsistent and surprising naming I could find, other categories are probably also conceivable. Another subject for reconsideration would be attribute and argument names, but I haven't looked for those in my quick survey.
For all of these inconsistencies, I think we should make a 'consistently' named alternative, and alias the original variant with them (or the other way around), without defining a deprecation timeline for the original names. This should make it possible to eventually make the stdlib consistent, Pythonic and unsurprising.
What would you think of such an effort?
Regards, Ralph Broenink
[1] https://mail.python.org/pipermail/python-ideas/2010-January/006755.html [2] https://mail.python.org/pipermail/python-dev/2009-March/086646.html
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/