[Python-ideas] Making the stdlib consistent again

Julien Duponchelle julien at gns3.net
Mon Aug 1 06:41:19 EDT 2016 

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/b521dc6b/attachment-0001.html>

More information about the Python-ideas mailing list