On 23/03/2016 06:09, Ben Finney wrote:
The problem is that Bart simultaneously is a beginner at Python, and
expresses astonishment that everyone shrugs when Bart's
dreadfully-written code performs so badly.
My interests differ from most people here writing Python.
For example, I'm interested in byte-code (any byte-code) and what can be
done with it. Investigating how well it performs in 'extreme' cases
means executing algorithms predominantly in byte-code, not measuring how
well some library function (in some unspecified language) can cope with
the algorithm.
And doing it 'Pythonically' can lead to suggestions such as the
following the other day:
c, psource = psource[0], psource[1:]
(where psource is a very long string), which even I could tell, from
knowing what goes on behind the scenes, wasn't going to work well
(duplicating the rest of the string roughly every other character).
A couple of years ago I had a project which tried to use a universal
syntax to express algorithms, and translating it into various languages.
The following code was generated for Python.
(/This/ is also quite a good way of learning a language, by figuring out
how to implement a specific feature in one language, in another. Another
way is to try and implement it...)
'N-Sieve' benchmark:
# Python source output
import sys
import math
import copy
def nsieve(m):
flags = ([1]*(m+1))
count = 0
for i in range(3,m+1):
if flags[i]:
count += 1
j = (i+i)
while (j<=m):
if flags[j]:
flags[j] = 0
j = (j+i)
sys.stdout.write(str("Primes up to "))
sys.stdout.write(str(m))
sys.stdout.write(str(": "))
sys.stdout.write(str(count))
sys.stdout.write("\n")
return count
def start():
nsieve(5120000)
nsieve(2560000)
nsieve(1280000)
start()
(The sys writes are used as it was easier than figuring out how to
reliably control spacing and newlines using 'print'. The m+1's I think
are there because the algorithm I used was 1-based).
In the case of this project, the source syntax was intended as a wrapper
around actual Python; it was not a language in its own right. (Although,
these simple benchmarks could generate Python, Lua or Lisp from the
exact same source. I know zilch about Lisp, except what I had to figure
out to make this work, and which I promptly forgot again. But the
resulting code ran perfectly!)
But I'd be more interesting now in translating another actual language
to Python. Now, the resulting Python is likely to be low-quality, with
extra code needed to match the source semantics. Then performance could
well be a factor not entirely offset by the novelty of watching Python
flawlessly execute a program not written in Python.
Good faith is contradicted by asserting knowledge of Python, complaining
about how some deliberately non-idiomatic Python code is performing
poorly, dismissing suggestions for improvement — specifically in the
context of someone who admittedly knows so little about Python.
Someone could be interested in cars, mechanics and performance without
wanting to know the most Pythonic way to get from Kings Cross to Heathrow.
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
