[Python-ideas] Making the stdlib consistent again

[Eugene Pakhomov]

I'm on Ralph's side here. "Why is this thing named the other way?" was one
of the first questions I asked. And people whom I occasionally teach about
Python, ask the same question over and over again.

Code breakage happens (PEP 3151 - didn't know about it till it almost bit
my leg off), so we can't shy away from it completely.
Is there any link on the previous thoughts of the core devs on the matter?
Especially regarding the amount of potential code breakage.
I'm genuinely interested, as I think that this amount is negligible if the
new names will be gradually introduced along with a deprecation notice
on (end eventual removal of) the old ones.
As far as I can see, it can only do some harm if someone uses a discouraged
"import *" or monkey-patches some new methods into Python standard
classes/modules, and updates his Python installation.

Regards,
Eugene


On Mon, Aug 1, 2016 at 1:46 AM, Ralph Broenink <ralph at ralphbroenink.net>
wrote:

> 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/
>>>
>>
> _______________________________________________
> 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/20160801/af547c61/attachment-0001.html>