[Python-ideas] Making the stdlib consistent again

Giampaolo Rodola' g.rodola at gmail.com
Mon Aug 1 10:51:24 EDT 2016 

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
>

Python 3 already broke quite a lot of stuff "just to be
better/more-consistent" and we're still into a state where there are many
people stuck with Python 2.7 because the migration cost is considered too
high or just not worth it.
Introducing such a change would increase this cost and make the two Python
versions (2 and 3) even more different.
It also has a mnemonic cost because you double the size of API names you'll
have to remember for virtually zero additional value other than the fact
that the names are more consistent. I understand the rationale but I think
any proposal making Python 3 more incompatible with python 2 should have a
*very* huge barrier in terms of acceptance.



> 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/
>



-- 
Giampaolo - http://grodola.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160801/ecce7db6/attachment-0001.html>

More information about the Python-ideas mailing list