[Python-ideas] Making the stdlib consistent again

[Brett Cannon]

On Mon, 25 Jul 2016 at 13:03 Mark Mollineaux <bufordsharkley at gmail.com>
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


>
> On Mon, Jul 25, 2016 at 10:55 AM, Ralph Broenink
> <ralph at ralphbroenink.net> wrote:
> > 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 treatment,
> but
> > 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
> 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 at python.org
> > https://mail.python.org/mailman/listinfo/python-ideas
> > Code of Conduct: http://python.org/psf/codeofconduct/
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160726/dc421322/attachment.html>