<div dir="auto"><div>Exactly. This is how Python came to be in the first place. Benchmarks are great, but don't underestimate creativity.<br><div class="gmail_extra"><br><div class="gmail_quote">On Jul 19, 2017 8:15 AM, "Antoine Pitrou" <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, 19 Jul 2017 14:59:52 +0200<br>
Victor Stinner <<a href="mailto:victor.stinner@gmail.com">victor.stinner@gmail.com</a>> wrote:<br>
>  Hi,<br>
><br>
> On Twitter, Raymond Hettinger wrote:<br>
><br>
>    "The decision making process on Python-dev is an anti-pattern,<br>
> governed by anecdotal data and ambiguity over what problem is solved."<br>
><br>
> <a href="https://twitter.com/raymondh/status/887069454693158912" rel="noreferrer" target="_blank">https://twitter.com/raymondh/<wbr>status/887069454693158912</a><br>
><br>
> About "anecdotal data", I would like to discuss the Python startup time.<br>
<br>
And I would like to step back and examine the general criticism of<br>
"anecdotal data".  Large software and hardware companies have the<br>
resources to conduct comprehensive surveys of how people use their<br>
products.  For example, Intel might have accumulated millions of traces<br>
of critical production x86 code that they want to keep running<br>
efficiently (or even keep running at all). Apple might have thousands<br>
of third-party applications which they can simulate running on a newer<br>
version of whatever OS, core library or pieces of hardware those<br>
applications rely on.  Even Google may nowadays have hundreds or<br>
thousands of critical services written in Go, and they may be able to<br>
assess the effect of further changes of the Go runtime on those<br>
services (not sure they do, but they would certainly have the resources<br>
to).<br>
<br>
CPython is a comparatively small, disorganized and volunteer-based<br>
community.  It doesn't have the resources or organization required to<br>
lead such studies on a regular basis.  Chances are it will never have.<br>
So all we can rely on is 1) our respective individual experiences in<br>
the field 2) anecdotal data.<br>
<br>
When we rewrote the Python 3 IO stack in C, we were relying on our<br>
intuition that high-performance IO is important, and on anecdotal data<br>
(micro-benchmarks) that the pure Python IO stack is slow.  When Tim or<br>
Raymond tweak the lookup function for dicts, they rely on anecdotal data<br>
delivered by a few select micro-benchmarks, and their intuition that<br>
some use cases need to be fast (for example dicts with string keys or<br>
keys made up of consecutive integers).  We don't have any hard data<br>
that all those optimizations are necessary for the majority of Python<br>
applications.  I don't think anybody in the world has statistically<br>
sound data about the entire body of Python code, or even a sufficiently<br>
large and relevant subset thereof (such as "Python code used in<br>
production for critical services").<br>
<br>
We aren't scientists.  We are engineers and have to make with whatever<br>
anecdotes we are aware of (be they from our own experiences, or users'<br>
complaints). We can't just say "yes, there seems be a performance issue,<br>
but I'll wait until we have non-anecdotal data that it's important".<br>
Because that day will probably never come, and in the meantime our<br>
users will have fled elsewhere.<br>
<br>
Regards<br>
<br>
Antoine.<br>
<br>
<br>
______________________________<wbr>_________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/guido%40python.org" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/options/python-dev/<wbr>guido%40python.org</a><br>
</blockquote></div><br></div></div></div>