The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Steven D'Aprano]

On Mon, 21 Mar 2016 06:47 pm, Ben Finney wrote:

> Steven D'Aprano <steve+comp.lang.python at pearwood.info> writes:
> 
>> On Monday 21 March 2016 13:11, Ben Finney wrote:
>> > Please, stop making assertions about Python code until you have
>> > learned Python.
>>
>> I don't see how "I don't have a clue about exceptions" is an assertion
>> about Python code.
> 
> That's not the assertion. I'm asking Bart to acknowledge that, because
> of the ignorance he admits to above, he should not be making elsewhere
> the sky-is-falling assertions about Python's failings.

I haven't seen these assertions that the sky is falling. What I have seen is
some benchmarks which purport to show that Python performs poorly compared
to Bart's custom language, which he describes as "dynamic", and Bart trying
to understand the design decisions which lead to this poor performance.

In fact, Bart even described one of those benchmarks as demonstrating that
Python was fast enough to be usable for typical tasks he performs (albeit
at the slow end of usable), so I believe that he is writing them in good
faith.


>> I'll ask everyone to please give Bart the benefit of the doubt and
>> assume good faith.
> 
> Bart is continuing to demonstrate *bad* faith by showing un-idiomatic
> Python code in support of his claims about how bad Python is, while
> simultaneously being confessedly ignorant about idiomatic Python.

Idiomatic like this example from the standard library?

https://hg.python.org/cpython/file/2.7/Lib/shlex.py


I do not believe that unfamiliarity with a language is prima facie evidence
of bad faith, and I do not believe that it is reasonable for us to demand
that programmers spend months or years learning all the idioms of a
language before judging whether or not it is fast enough for the types of
tasks they plan to use it for.

There are many users of Python, of many varying degrees of skill and
knowledge, and they don't always write what experts will call "idiomatic"
code. In the real world, people will write unidiomatic code. Don't you
think it would be good if Python was as fast as it could be even if your
code was less than perfect?

Besides, nobody has demonstrated that re-writing Bart's code would make it
significantly faster. Maybe it will double the speed. Maybe it will improve
times by 10%. Or maybe it won't make any real difference.


> Bart can show good faith by *learning* idiomatic Python, with the
> humility of a beginner. And also by refraining from rhetoric about how
> bad Python's performance is, until he gains experience to make those
> claims.

"Humility of a beginner"... what a strange phrase to use about somebody who
has been programming for decades. What exactly is the problem here? Is it
that Bart hasn't earned the right to say what we all know, that Python is
slow, because he's an outsider?

I mean, honestly, Bart has written some code to read text from a file and
parse it, found it is slow, and some people are rejecting the results
because he's unwisely suppressed tracebacks using bare excepts. How does
this invalidate his results? If you change the "except" to "except
IOError", will that magically speed up the script by a factor of five? I
don't think so.

We all know that Python can be quite slow, and the Python community has many
work-arounds for this fact, most of which come down to "write the slow bits
in C". Look how much of the standard library is either written in C or thin
wrappers around C: the builtins themselves, math, decimal, array, binascii,
bisect, pickle, datetime, itertools, heapq and more. There's even an entire
module designed to let you call C functions from within Python:

https://docs.python.org/3/library/ctypes.html

(Jython and IronPython don't have anything like this, but instead they have
interfaces for calling Java and .Net code.)

In some ways, Python could be considered a wrapper around C, and perhaps
even when that's not entirely accurate, it is good to remember that Python
started off as a glue language for C and Fortran libraries.

I think Bart is perfectly entitled to carry on investigating the speed of
Python using the styles of coding he is used to, and compare it to his own
language. If this group was half as welcoming and friendly as we like to
tell ourselves we are, we'd be helping him to write more idiomatic code,
which hopefully will be faster, but realistically may not be, not telling
him to bugger off until he's learnt more Python, not dismissing his
benchmarks as invalid because they're not idiomatic, and especially not
sneering at him for a few poor coding choices in a script which is
prominently flagged at the top of the file as "buggy" and not for
production use.



-- 
Steven