[Python-ideas] Making the stdlib consistent again

[Eugene Pakhomov]

Thank you very much for the links and the new insights, especially
regarding actual user experience with new names. A good reason to start
gathering actual statistics.
You have made a very good point, I will not reason about naming
further without a significant amount of data showing that it still may be
worth it.

Regards,
Eugene


On Mon, Aug 1, 2016 at 7:51 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 1 August 2016 at 20:05, Eugene Pakhomov <p1himik at 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 at gmail.com   |   Brisbane, Australia
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160801/e0c3e019/attachment.html>