On 21/03/2016 16:30, Steven D'Aprano wrote:
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.
Yes, on my machine even Python 3 can apparently tokenise C at around 40K
lines per second. But this varies depending on the density of the
source. On other inputs, it might achieve over 50Klps. And this was the
slowest of the Pythons tested; others will be faster. My machine isn't
the fastest either.
So, even though this test only does the lowest level of tokenising (the
next steps are doing name lookups, and then actual parsing), I think it
is quite practical to use Python in tasks like this.
(Note that my gcc C compiler can only compile at 2-5 Klps, peaking at
12Klps with input in one large. Compared to that, the Python timing
isn't too bad.)
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
