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@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@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@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@python.org> wrote:
>>>
>>> On Mon, 25 Jul 2016 at 13:03 Mark Mollineaux <bufordsharkley@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@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@python.org
>>>> > https://mail.python.org/mailman/listinfo/python-ideas
>>>> > Code of Conduct: http://python.org/psf/codeofconduct/
>>>> _______________________________________________
>>>> Python-ideas mailing list
>>>> Python-ideas@python.org
>>>> https://mail.python.org/mailman/listinfo/python-ideas
>>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>>
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/



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