On 1 August 2016 at 20:05, Eugene Pakhomov <p1himik@gmail.com> wrote:
> It was hardly all of the thoughts, or at least with little background
> information.

The most pertinent piece of background information is
http://www.curiousefficiency.org/posts/2011/02/status-quo-wins-stalemate.html

The number of changes we *could* make to Python as a language is
theoretically unbounded. "Can you get current core developers
sufficiently enthusiastic about your idea to encourage you to see it
through to implementation?" is thus one of the main defenses the
language has against churn for churn's sake (it's definitely not the
only one, but it's still a hurdle that a lot of proposals fail to
clear).

> 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)?

All at once, and the old names haven't been removed, and will likely
remain supported indefinitely (there's nothing technically wrong with
them, they just predate the introduction of the descriptor protocol
and Python's adoption of snake_case as the preferred convention for
method and attribute names, and instead use the older Java-style API
with camelCase names and explicit getter and setter methods).

The implementation issue is http://bugs.python.org/issue3042 but
you'll need to click through to the actual applied patches to see the
magnitude of the diffs (the patches Benjamin posted to the tracker
were only partial ones to discuss the general approach).

For a decent list of other renames that have largely been judged to
have created more annoyance for existing users than was justified by
any related increase in naming consistency, the six.moves
compatibility module documentation includes a concise list of many of
the renames that took place in the migration to Python 3:
https://pythonhosted.org/six/#module-six.moves

I've yet to hear a professional educator proclaim their delight at
those renaming efforts, but I *have* received a concrete suggestion
for improving the process next time we decide to start renaming things
to improve "consistency": don't do it unless we have actual user
experience testing results in hand to show that the new names are
genuinely less confusing and easier to learn than the old ones.

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

That's the second great filter for language change proposals: is there
at least one person (whether a current core developer or not) with the
necessary time, energy and interest needed to implement the proposed
change and present it for review?

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

Aside from adding new methods to existing classes (which may collide
with added methods in third party subclasses) and the text mock
example Paul cited, additions to existing modules almost never break
things. By contrast, removals almost *always* break things and hence
are generally only done these days when the old ways of doing things
are actively harmful (e.g. the way the misdesigned contextlib.nested
API encouraged resource leaks in end-user applications, or the blurred
distinction between text and binary data in Python 2 encouraged
mishandling of text data).

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

If it's a programmatic deprecation (rather than merely a documented
one), then deprecation absolutely *does* force folks that have a "no
warnings" policy for their test suites to update their code
immediately. It's the main reason we prefer to only deprecate things
when they're actively harmful, rather than just because they're no
longer fashionable.

While standard library module additions can indeed pose a
compatibility challenge (due to the way module name shadowing works),
the typical worst case scenario there is just needing some explicit
sys.path manipulation to override the stdlib version specifically for
affected applications, and even that only arises if somebody has an
existing internal package name that collides with the new stdlib one
(we try to avoid colliding with names on PyPI).

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

That's a different proposal from wholesale name changes, as it allows
each change to be discussed on its individual merits rather than
attempting to establish a blanket change in development policy.

> The perfect example I think is collections module, but it's only from the
> personal experience - other modules may be better candidates.

collections has the challenge that the normal PEP 8 guidelines don't
apply to the builtins, so some collections types are named like
builtins (deque, defaultdict), while others follow normal class naming
conventions (e.g. OrderedDict). There are also type factories like
namedtuple, which again follow the builtin convention of omitting
underscores from typically snake_case names.

> I can't say that I surely do not underestimate the efforts required. But
> what if I want to invest my time in it?

It's not contributor time or even core developer time that's the main
problem in cases like this, it's the flow on effect on books,
tutorials, and other learning resources. When folks feel obliged to
update those, we want them to able to say to themselves "Yes, the new
way of doing things is clearly better for my students and readers than
the old way".

When we ask other people to spend time on something, the onus is on us
to make sure that at least we believe their time will be well spent in
the long run (even if we're not 100% successful in convincing them of
that in the near term). If even we don't think that's going to be the
case, then the onus is on us to avoid wasting their time in the first
place. We're never going to be 100% successful in that (we're always
going to approve some non-zero number of changes that, with the
benefit of hindsight, turn out to have been more trouble than they
were worth), but it's essential that we keep the overall cost of
change to the entire ecosystem in mind when reviewing proposals,
rather than taking a purely local view of the costs and benefits at
the initial implementation level.

> 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"?

It would depend on the specific change you propose, and the rationale
you give for making it. If the only rationale given is "Make <API>
more compliant with PEP 8", then it will almost certainly be knocked
back.

Cheers,
Nick.

--
Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia