<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-07-25 10:55 GMT-07:00 Ralph Broenink <span dir="ltr"><<a href="mailto:ralph@ralphbroenink.net" target="_blank">ralph@ralphbroenink.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi python-ideas,</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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 treatment, but unfortunately this was not expanded to all modules. </div><div><br></div><div>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 them:</div><div><br></div><div>  * 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.</div><div><br></div><div>  * 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.</div><div><br></div></div></blockquote><div>Does that also go for builtin classes, such as int and str and object and type?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>  * 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.</div><div><br></div><div>  * Names that do not reflect actual usage, such as ssl.PROTOCOL_SSLv23, which can in fact not be used as client for SSLv2. </div><div><br></div><div>  * 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)?</div><div><br></div><div>  * Usage of various abbreviations, such as in filecmp.cmp </div><div><br></div><div>  * Inconsistencies between similar modules, e.g. between tarfile.TarFile.add and zipfile.ZipFile.write.</div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>What would you think of such an effort?</div><div><br></div><div>Regards,</div><div>Ralph Broenink</div><div><br></div><div> [1] <a href="https://mail.python.org/pipermail/python-ideas/2010-January/006755.html" target="_blank">https://mail.python.org/pipermail/python-ideas/2010-January/006755.html</a></div><div> [2] <a href="https://mail.python.org/pipermail/python-dev/2009-March/086646.html" target="_blank">https://mail.python.org/pipermail/python-dev/2009-March/086646.html</a></div><div><br></div></div>
<br>_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofconduct/</a><br></blockquote></div><br></div></div>