On Fri, Feb 23, 2018 at 6:06 PM, bartc <b...@freeuk.com> wrote:
> On 24/02/2018 00:45, Dan Stromberg wrote:
>> But again, those techniques are only infrequently relevant, and pretty
>> much never relevant to an entire application.
> That your page lists 23 different approaches to making Python faster
> suggests that its speed can be an issue. Certainly there seem to be a lot of
> projects going on trying to fix that aspect.

Of course CPU performance can be an issue. For any language.

When I was a kid, programs were written in BASIC.  If BASIC was too
slow, you'd rewrite the hotspots in assembler.  Does that mean
everything should have been written in assembler?  Not at all.
Assembler was slow to code in and tended to produce crashy solutions.

Obsessing about CPU time is outdated thinking for almost all problems.
Developer time is much more likely to matter to the bottom line

> Perhaps it ought to have been clear that this was CPython, if it in fact
> was.

CPython != Python.  g++ != C++.  gcc != C.

Python is a language.  Not an implementation of a language.

> There are so many possibilities with Python, that using anything else
> would confuse matters.

Gosh no.  A language's success can, in significant part, be judged by
the number of compatible implementations and dialects.

You might find this interesting:

It's just one microbenchmark, but it's me addressing someone asking
why Python is so much slower than C++.

Reply via email to