views:

341

answers:

2

I've been playing with pyglet. It's very nice. However, if I run my code, which is in an executable file (call it game.py) prefixed with the usual

#!/usr/bin/env python

by doing

./game.py

then it's a bit clunky. But if I run it with

python -O ./game.py

or

PYTHONOPTIMIZE=1 ./game.py

then its super-smooth.

I'm don't care much why it runs slow without optimization; pyglet's documentation mentions that optimizing disables numerous asserts and also OpenGL's error checking, and I'm happy to leave it at that.

My question is: how do people distributing Python code make sure the end users (with zero interest in debugging or modifying the code) run the optimized version of the code. Surely there's some better way than just telling people to make sure they use optimization in the release notes (which they probably won't read anyway) ?

On Linux I can easily provide a ./game script to run the file for end users:

#!/bin/sh
PYTHONOPTIMIZE=1 ./game.py $*

but that's not very cross-platform.

I have an idea I ought to be able to change the #! line to

#!/usr/bin/env PYTHONOPTIMIZE=1 python

or

#!/usr/bin/env python -O

but those don't seem to work as expected, and I'm not sure what they'd do on Windows.

Is there some way of controlling optimization from within the code I'm unaware of ? Something like:

  import runtime
  runtime.optimize(True)

What's considered best-practice in this area by people shipping multi-platform python code ?

+13  A: 

"On Linux I can easily provide a ./game script to run the file for end users:"

Correct.

"but that's not very cross-platform."

Half-correct. There are exactly two shell languages that matter. Standard Linux "sh" and Non-standard Windows "bat" (a/k/a cmd.exe) and that's all there is nowadays. [When I was a kid, there was Open VMS DCL and Data General's weird shell language and RSX-11 and all kinds of great stuff. Thank God for the Posix standard.]

game.sh

python -O game.py

game.bat

python -O game.py

Interestingly the files are the same, only the extension (and the file format) had to be changed to make the various OS's happy.

If you want true one-size-fits-all cross platform, you have to remember that Python is a shell language. This kind of thing works, also.

game-startup.py

import subprocess
subprocess.Popen( "python -O game.py" )
S.Lott
Thanks! I like it when a problem has a nice simple solution.
timday
+2  A: 

Answering your question (as opposing to fixing your problem, which S. Lott did perfectly), I think a lot of the time people who distribute Python code don't worry about this, because it's rare for the optimisation flag to have any effect. I believe Pyglet is the only exception I've heard of in years of using Python. Quoting from the Python docs, "The optimizer currently doesn’t help much; it only removes assert statements".

Kylotan
Likewise: this is the first time I've seen the optimize flag make any noticeable difference at all to any python code. The code which caused me to raise the question uses a large number of "immediate mode" GL calls; I suspect (haven't checked) pyglet does various asserts (probably including a glGetError) for every single one and it all adds up.
timday
But -OO removes all docstrings, which can lead to surprises. Matplotlib uses programmatically constructed docstrings, e.g. %s escapes in the docstring that are substituted with f.__doc__ = f.__doc__ % kwdict, which causes an error when running with -OO.
Jouni K. Seppänen