Hi Terry,
On 13/05/2021 5:32 am, Terry Reedy wrote:
On 5/12/2021 1:40 PM, Mark Shannon wrote:
This is an informational PEP about a key part of our plan to improve
CPython performance for 3.11 and beyond.
As always, comments and suggestions are welcome.
The claim that starts the Motivation section, "Python is widely
acknowledged as slow.", has multiple problems. While some people
believe, or at least claim to believe "Python is slow", other know that
as stated, the latter is false. Languages do not have a speed, only
implementations running code for particular applications have a speed,
or a speed relative to equivalent code in another language with a
different runtime.
I broadly agree, but CPython is largely synonymous with Python and
CPython is slower than it could be.
The phrase was not meant to upset anyone.
How would you rephrase it, bearing in mind that needs to be short?
I reason I am picking on this is that the meme 'Python is slow' is being
morphed into 'Python is destroying the earth' (and should be abandoned,
if not banned). Last fall, a science news journal (Nature News?) quoted
a 'concerned scientist' saying just this. An internet troll repeated it
last week on comp.lang.python (from where it leaked onto python-list).
It is a legitimate concern that CPython is bad for the environment, and
one that I hope we can address by speeding up CPython.
Since, faster == less energy for the same amount of work, making CPython
faster will reduce the amount of CO2 produced to do that work and
hopefully make it less of a concern.
Of course, compared to the environmental disaster that is BitCoin, it's
not a big deal.
It is true that Python has characteristics that make it *relatively*
difficult to write interpreters that are *relatively* fast in certain
applications. But the opposite is also true. The language does *not*
mandate that objects, their methods, and modules be written in the
language.
Hence, CPython implements builtin objects and function and some stdlib
modules in C and allows 3rd party modules written in C or C++ or
Fortran. I believe the first killer app for Python, in the mid 1990s,
numerical computing with NumericalPython. Rather than being 'slow',
CPython *enabled* people, with a few percent of added time, to access
fast, heavily optimized C and Fortran libraries and do things they could
not do in Fortran and that would have been much more difficult in C. My
daughter's PhD thesis work is a recent example of using Python to access
C libraries.
Yes, one of the great things about Python is that almost every library
of any size has Python bindings.
But there is a difference between making code that is already written in
C/Fortran available to Python and telling people to write code in
C/Fortran because their Python code is too slow.
We want people to be able to write code in Python and have it perform at
the level they would get from a good Javascript or lua implementation.
The concerned scientist mentioned above noted, more or less correctly,
that numerical code, such as neuro-network code, is, say, 80x slower in
pure python than in compiled C. But he did not mention that serious
numerical and scientific work in Python is not done with such code.
I have seen this sort of bogus comparison before.
It is still important to speed up Python though.
If a program does 95% of its work in a C++ library and 5% in Python, it
can easily spend the majority of its time in Python because CPython is a
lot slower than C++ (in general).
Cheers,
Mark.
https://www.python.org/dev/peps/pep-0659/
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/QAWW7I733TPNU4VE2I4J2FCPCXXVM7MG/
Code of Conduct: http://python.org/psf/codeofconduct/
