[Python-ideas] Making the stdlib consistent again

[Ralph Broenink]

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 <brett at python.org> wrote:

> 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/20160731/f5d74901/attachment.html>