[Python-ideas] Shuffled

[Nick Coghlan]

On 8 September 2016 at 12:00, Steven D'Aprano <steve at pearwood.info> wrote:
> On Wed, Sep 07, 2016 at 11:43:59PM +0200, Sven R. Kunze wrote:
>
>> BUT experienced devs also need to recognize and respect the fact that
>> younger/unexperienced developers are just better in detecting
>> inconsistencies and bloody work-arounds.
>
> That is not a fact. It is the opposite of a fact -- inexperienced
> developers are WORSE at spotting inconsistencies, because they don't
> recognise deep consistencies.

There are also cases where we're internally inconsistent or lacking
internal integration because we're being consistent with different
external environments.

So we have both binary floating point and decimal floating point
because there are inherent conflicts in the underlying computational
models.

We have both the abc module (which deals strictly with runtime
classes) and the typing module (which deals strictly with type
categories) as those things are similar, but not the same.

We have both asyncio and traditional synchronous APIs as there are
essential conflicts between blocking and non-blocking models of
control flow.

Cross-platform secure network connectivity handling is a pain because
many of the underlying platform APIs are unreliably implemented and
poorly documented moving targets.

Cross-platform software distribution is a pain largely because major
platform vendors are typically competing to lock in developers, so
their incentives are aligned with making what we're trying to do
difficult rather than offering to help out.

For these kinds of cases, frustrations on the part of experienced
developers arise when folks ask entirely reasonable questions "Why is
<topic area> so complicated?", but then refuse to accept the answer of
"Because it's genuinely complex". Pretending complexity doesn't exist
doesn't help anyone - it means they're left to their own devices to
come up with answers, rather than receiving more explicit guidance at
the language level.

More directly relevant to the current discussion is the principle of
"Not every three line function needs to be a builtin (or even in the
standard library)". There are ways to collect objective data on the
relative usage of particular constructs (especially as hosting
platforms like GitHub team up with analytics platforms like Google Big
Query to make their data searchable, and initiatives like Software
Heritage aim to bring that kind of capability to all published open
source software), but one of the *simplest* criteria to apply, and the
one that experienced core developers can typically answer without
further research, is "Would the standard library benefit from this?".

When the answer to that is "No", then the default answer to requests
for API additions that are relatively easy for people to implement for
themselves is always going to be "No" - otherwise the stdlib will
collapse under its own weight (and the persistent "up and to the
right" trend on http://bugs.python.org/issue?@template=stats means
that there's a solid argument to be made that the standard library is
already bigger than we can effectively maintain at current maintenance
funding levels).

Cheers,
Nick.

P.S. I wrote http://www.curiousefficiency.org/posts/2011/04/musings-on-culture-of-python-dev.html
about this a few years ago, and I still think it's an accurate
description of the underlying causes of these conflicts

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