[Python-ideas] Making the stdlib consistent again

Sun Jul 31 20:39:39 EDT 2016

Thoughts of the core dev were expressed clearly earlier in this thread.

On Sun, Jul 31, 2016 at 12:47 PM, Eugene Pakhomov <p1himik at gmail.com> wrote:
> 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/
>
>
>
> _______________________________________________
> 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/

-- 
--Guido van Rossum (python.org/~guido)