On 07/03/2016 19:10, Chris Angelico wrote:
On Tue, Mar 8, 2016 at 5:34 AM, BartC <b...@freeuk.com> wrote:
def abortjpeg(mess):
print ("Error:",mess)
raise
Here's my Python:
RuntimeError: No active exception to reraise
OK I'll have a look. (Or maybe just change 'raise' to 'exit(0)'. It just
needs to crash out at this point, but should be a bit more graceful than
what you had.)
I disagree. The program does its job perfectly (you will have to take it
further to verify the results, such as writing out the .ppm file and viewing
the contents).
But Py3 is slower doing this task than Py2 by 10 or 20% (or even 30% for a
smaller file). /This is in line with other observations./
What's your meaning of "perfectly"? You're implementing things in a
very C way, and then showing that two different Python interpreters
have different performance.
Two interpreters executing exactly the same code and exactly the same
algorithm. And for a real task which deliberately doesn't just delegate
to high-level features (otherwise you're just comparing libraries).
What can be more perfect for comparing two implementations?
You haven't actually shown how a
properly-written program would perform.
If I could find one that worked, I would have used that! (But I was more
interested in 3 vs. PyPy than 2 vs. 3.)
Did you try the 'pillow' library?
https://pypi.python.org/pypi/Pillow
It supports 2.6/2.7 and 3.2+, and would be most people's "one obvious
way" to do things. At very least, it should get a mention in your
performance comparisons.
I don't understand. This is an external library that appears to be
written in C. How does that help me compare the performance of two
implementations of Python?
One could be ten times slower than the other (in executing its native
bytecode), but if it spends 99% of its time an a C image library, how do
you measure that?
(I'm quite pleased with my version: smaller, faster, works on all the
Pythons, supports all 3 colour formats and no decoding bugs that I'm aware
of, and it's the first Python program I've written that does something
useful.)
"all the Pythons" meaning what, exactly?
I means versions 2 and 3 of the language, tested on CPython versions
2.5, 2.7, 3.1 and 3.4, as well as PyPy. The other decoders I tried were
for 2.x.
And, no decoding bugs? Maybe,
but I wouldn't bet my life on it. Unless your code is a pure port of
someone else's (and unless that someone else could guarantee that the
original C code was bug free), I wouldn't trust code that I can't
completely analyze in one sitting. Virtually all code has bugs in it;
the only code that doesn't is code that's so trivially simple that you
can completely understand it in one "headspace".
Let's put it this way: I don't have to hand a jpeg file that it can't
decode. When one turns up then I will fix that. (I can't say for sure
there aren't any subtle chroma or quality problems, but there's nothing
obvious.) I can't say that for the decoders I looked at.
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
