On 8 September 2016 at 12:00, Steven D'Aprano <st...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
