On Mon, 21 Mar 2016 06:47 pm, Ben Finney wrote: > Steven D'Aprano <steve+comp.lang.pyt...@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 -- https://mail.python.org/mailman/listinfo/python-list
