On Tue, Mar 8, 2016 at 5:34 AM, BartC <b...@freeuk.com> wrote:
> On 07/03/2016 15:31, Chris Angelico wrote:
>>
>> On Tue, Mar 8, 2016 at 12:25 AM, BartC <b...@freeuk.com> wrote:
>
>
>>> (The Python version of that program is here:
>>> http://pastebin.com/cHx3UhQb. It should work with any Python.)
>>
>>
>> Actually, it won't work with any Python - not if it gets a broken
>> file. Your abortjpeg() function doesn't work :)
>
>
> What does it do when it doesn't work? I just get 'can't load file' then it
> stops if there's no such file. With an extra message if there's a format
> error. (I'm not sure what 'raise' does, but it doesn't complain about it. I
> think I realised I didn't know what came next and left it.)
Here's your code:
def abortjpeg(mess):
print ("Error:",mess)
raise
Here's my Python:
$ python3
Python 3.6.0a0 (default:bbfbde6ee9d0, Feb 19 2016, 12:43:06)
[GCC 5.3.1 20160121] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> raise
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
RuntimeError: No active exception to reraise
The only try/except in your code (an except block is the only way
you'll have an "active exception") is this abomination:
def getfile(file):
try:
data=open(file,"rb").read()
except:
return 0
...
>> But what you have there is a messy mixture of old-style classes used
>> as if they were C structs, array.array() as if it were a C array, and
>> utterly uncommented code that looks like it was ported from, again, C.
>> Benchmarking Py2 vs Py3 on that kind of code is like trying to figure
>> out whether it's easier to drag a 747 by your teeth or your toes.
>> Yeah, you might get a result, but it's a useless one.
>
>
> 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. You haven't actually shown how a
properly-written program would perform.
>> You're not going to prove anything useful about Python - any version
>> of Python - by using it badly. Try implementing JPEG decoding in a
>> more Pythonic way - or, better still, use pillow and don't write that
>> kind of code yourself at all.
>
> Before I wrote this, I looked at three other existing Python decoders, all
> more Pythonic (one had been ported from C++ I think and was crammed full of
> classes).
>
> One worked so poorly that it was dismissed. The other two were full of bugs
> and didn't fully support the 3 main colour formats, but when they did work,
> were 3-6 times slower than my version IIRC.
>
> They also only worked with Python 2 (so presumably would have been even
> slower on 3!) It also meant I couldn't test PyPy on them. I tried psyco but
> it made little difference. And actually the main purpose was to have
> something substantial to try PyPy on.
>
> So I don't know who's using Python more badly: me or those other authors.
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'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? 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".
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
