[Python-ideas] Making the stdlib consistent again

Eugene Pakhomov p1himik at gmail.com
Mon Aug 1 06:45:34 EDT 2016 

There's always a lot of people that don't want to make some changes. It
doesn't mean that we have to keep every old piece at its place.
We can keep deprecated names for a really long time, yes - maybe even until
we introduce some required and definitely breaking change in the related
module. But the names still will be deprecated and their use hence will be
discouraged - there's no confusion at all.

Regards,
Eugene


On Mon, Aug 1, 2016 at 5:41 PM, Julien Duponchelle <julien at gns3.net> wrote:

> A lot of people will not want to invest time to rewrite their code to use
> the consistent stdlib because they will not see immediate/enough benefits.
> This mean you will need to keep the alias forever creating more confusion
> for users because they will have two function doing the same.
>
> Regards,
>
> Julien
>
> On Mon, Aug 1, 2016 at 12:05 PM Eugene Pakhomov <p1himik at gmail.com> wrote:
>
>> It was hardly all of the thoughts, or at least with little background
>> information.
>>
>> E.g. "multiprocessing and threading" - I can't find any information on
>> it. Was it done in one go or gradually by introducing new aliases and
>> deprecating old names, at it has been suggested by you (although it was 7
>> years ago)?
>>
>> The suggestion about aliases+deprecation has been made for other modules,
>> but sadly it ended up with you saying "let's do it this way" - with nothing
>> following.
>>
>> Or "you have to keep the old API around" - what is the exact motivation
>> behind it? If it's "so the code doesn't break", then it's a strange
>> motivation, because as I said, code gets [potentially] broken more often
>> that it doesn't. Every alteration/addition/deletion is a potential code
>> breakage a priory - aliasing+deprecation is in no way more dangerous than,
>> let's say, new zipapp module.
>>
>> I in no way state that the changes should include a complete overhaul or
>> be done in one go. But maybe we can at least start gradually introducing
>> some naming changes to the oldest, most used and least changed (w.r.t. API)
>> modules?
>> The perfect example I think is collections module, but it's only from the
>> personal experience - other modules may be better candidates.
>>
>> I can't say that I surely do not underestimate the efforts required. But
>> what if I want to invest my time in it? If let's say I succeed and do
>> everything according to the developer's guide and prove on a number of the
>> most popular libraries that the changes indeed do not break anything - will
>> be patch be considered or just thrown away with a note "we already
>> discussed it"?
>>
>> Regards,
>> Eugene
>>
>>
>> On Mon, Aug 1, 2016 at 7:39 AM, Guido van Rossum <guido at python.org>
>> wrote:
>>
>>> 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)
>>>
>>
>> _______________________________________________
>> 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/9d6dc42a/attachment-0001.html>

More information about the Python-ideas mailing list