<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, 25 Jul 2016 at 13:03 Mark Mollineaux <<a href="mailto:bufordsharkley@gmail.com">bufordsharkley@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've pined for this (and feel a real mental pain every time I use one<br>
of those poorlyCased names)-- I end up using a lot of mental space<br>
remembering exactly HOW each stdlib isn't consistent.<br>
<br>
Aliasing consistent names in each case seems like a real win all<br>
around, personally.<br></blockquote><div><br></div><div>For those that want consistent names, you could create a PyPI package that is nothing more than the aliased names as suggested.</div><div><br></div><div>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.</div><div><br></div><div>-Brett</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Mon, Jul 25, 2016 at 10:55 AM, Ralph Broenink<br>
<<a href="mailto:ralph@ralphbroenink.net" target="_blank">ralph@ralphbroenink.net</a>> wrote:<br>
> Hi python-ideas,<br>
><br>
> As you all know, the Python stdlib can sometimes be a bit of an inconsistent<br>
> mess that can be surprising in how it names things. This is mostly caused by<br>
> the fact that several modules were developed before the introduction of<br>
> PEP-8, and now we're stuck with the older naming within these modules.<br>
><br>
> It has been said and discussed in the past [1][2] that the stdlib is in fact<br>
> inconsistent, but fixing this has almost always been disregarded as being<br>
> too painful (after all, we don't want a new Python 3 all over again).<br>
> However, this way, we will never move away from these inconsistencies.<br>
> Perhaps this is fine, but I think we should at least consider providing<br>
> function and class names that are unsurprising for developers.<br>
><br>
> While maintaining full backwards compatibility, my idea is that we should<br>
> offer consistently named aliases in -eventually- all stdlib modules. For<br>
> instance, with Python 2.6, the threading module received this treatment, but<br>
> unfortunately this was not expanded to all modules.<br>
><br>
> What am I speaking of precisely? I have done a quick survey of the stdlib<br>
> and found the following examples. Please note, this is a highly opinionated<br>
> list; some names may have been chosen with a very good reason, and others<br>
> are just a matter of taste. Hopefully you agree with at least some of them:<br>
><br>
> * The CamelCasing in some modules are the most obvious culprits, e.g.<br>
> logging and unittest. There is obviously an issue regarding subclasses and<br>
> methods that are supposed to be overridden, but I feel we could make it<br>
> work.<br>
><br>
> * All lower case class names, such as collections.defaultdict and<br>
> collections.deque, should be CamelCased. Another example is datetime, which<br>
> uses names such as timedelta instead of TimeDelta.<br>
><br>
> * Inconsistent names all together, such as re.sub, which I feel should be<br>
> re.replace (cf. str.replace). But also re.finditer and re.findall, but no<br>
> re.find.<br>
><br>
> * Names that do not reflect actual usage, such as ssl.PROTOCOL_SSLv23,<br>
> which can in fact not be used as client for SSLv2.<br>
><br>
> * Underscore usage, such as tarfile.TarFile.gettarinfo (should it not be<br>
> get_tar_info?), http.client.HTTPConnection.getresponse vs set_debuglevel,<br>
> and pathlib.Path.samefile vs pathlib.Path.read_text. And is it<br>
> pkgutil.iter_modules or is it pathlib.Path.iterdir (or re.finditer)?<br>
><br>
> * Usage of various abbreviations, such as in filecmp.cmp<br>
><br>
> * Inconsistencies between similar modules, e.g. between<br>
> tarfile.TarFile.add and zipfile.ZipFile.write.<br>
><br>
> These are just some examples of inconsistent and surprising naming I could<br>
> find, other categories are probably also conceivable. Another subject for<br>
> reconsideration would be attribute and argument names, but I haven't looked<br>
> for those in my quick survey.<br>
><br>
> For all of these inconsistencies, I think we should make a 'consistently'<br>
> named alternative, and alias the original variant with them (or the other<br>
> way around), without defining a deprecation timeline for the original names.<br>
> This should make it possible to eventually make the stdlib consistent,<br>
> Pythonic and unsurprising.<br>
><br>
> What would you think of such an effort?<br>
><br>
> Regards,<br>
> Ralph Broenink<br>
><br>
> [1] <a href="https://mail.python.org/pipermail/python-ideas/2010-January/006755.html" rel="noreferrer" target="_blank">https://mail.python.org/pipermail/python-ideas/2010-January/006755.html</a><br>
> [2] <a href="https://mail.python.org/pipermail/python-dev/2009-March/086646.html" rel="noreferrer" target="_blank">https://mail.python.org/pipermail/python-dev/2009-March/086646.html</a><br>
><br>
><br>
> _______________________________________________<br>
> Python-ideas mailing list<br>
> <a href="mailto:Python-ideas@python.org" target="_blank">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>
_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">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></div>