On 19 July 2017 at 22:59, Victor Stinner <victor.stin...@gmail.com> wrote: > == CPython core developers don't care? no, they do care == > > Christian Heimes, Naoki INADA, Serhiy Storchaka, Yury Selivanov, me > (Victor Stinner) and other core developers made multiple changes last > years to reduce the number of imports at startup, optimize impotlib, > etc.
I actually also care myself, since interpreter startup time feeds directly into cost of execution when running in environments like AWS Lambda which charge by the "gigabyte second" (i.e. you allocate a certain amount of RAM to a particular command, and then get charged for that RAM for the amount of time it takes to run, as measured with subsecond precision - if you exceed the limits of the free tier, anything you 're losing to language runtime startup in such an environment translates almost directly to higher costs). In aggregate, shaving time off CPython startup saves *scary* amounts of collective compute time around the world - even though most runtime environments don't track that as closely in financial terms as Lambda does, we're still nudging the power & cooling requirements of data centers slightly higher than they would otherwise be. So even when the per-invocation impact of a performance improvement is small, it's worth keeping in mind that CPython gets invoked a *lot*, whether it's to respond to a web request, run a test, run a build, deploy another application, analyse some data, etc :) However, I'm also of the view that module & API maintainers *do* have the authority to set the design priorities for the parts of the standard library that they're personally responsible for, and if we'd like them to change their minds based on information we have that they don't, then reopening enhancement requests that they already closed is *not* the way to go about it (as while the issue tracker is an excellent venue for figuring out the technical details of a change, or deciding whether or not an RFE is a good idea given a common understanding of the relevant design priorities, it's almost always a *terrible* venue for resolving outright disagreements as to what the most relevant design priorities actually are). Rather, the best available way to publicly request reconsideration is the way Antoine did when he escalated the namedtuple question to python-dev: by explicitly acknowledging that there's a conflict in design priorities between core developers, and asking for a collective discussion (and potentially a determination from Guido) as to the right way forward for the project as a whole. Cheers, Nick. P.S. I'll also note that we're not *actually* limited to resolving such conflicts in public venues (even though I think that's a good default habit for us to retain): as long as we report the outcome of any mutual agreements about design priorities back to the relevant public venue (e.g. a tracker issue), there's nothing wrong with shifting our attempts to better understand each other's perspectives to private email, IRC, video chat, etc. A non-trivial number of previously vociferous arguments have been resolved amicably once the main parties involved have had a chance to discuss them in person at a conference or sprint. It can even make sense to reach out to other core devs for help, since it's almost always easier for someone not caught in the midst of an argument to see both sides of it, and potentially spot a core of agreement amidst various surface level disagreements :) -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com