Clean termination of daemon Python threads
2008-08-09 11:23:03
Daemonic threads in Python are threads that will not prevent the interpreter
from exiting (put another way, the interpreter shuts down when all non-daemon
threads exit). When the interpreter shuts down, all variables are set to None,
then each daemon thread is woken up to crash (unexpectedly finding all its
variables, globals and builtins missing).
Here's a nifty pattern that suppresses the ugly exception trace resulting from
these crashes being printed to the terminal:
def worker_thread():
try:
.... do work ...
except:
if True:
raise
This ensures ordinary exceptions are re-raised, but interpreter shutdown related
exceptions are suppressed, as True is evaluated as None. In the off-chance that
some future or alternative Python interpreter doesn't have the same strange
daemon thread shutdown behaviour, the thread will still behave correctly.
Annotate observed types in a Python program
2008-06-18 12:22:02
Neat script I wrote for a friend to
annotate a Python script with the types
observed during a run of the program. Usage:
python -m annotype test.py
With this script:
def foo(bar, baz):
pass
foo(1, 'a')
foo(2, 3)
Outputs 'out_annotype/test.py' with:
def foo(bar, baz):
# [annotype] bar: int
# [annotype] baz: str, int
pass
foo(1, 'a')
foo(2, 3)
Hopefully useful for discovering usage of undocumented APIs.
Python, meet Vista/64
2008-05-09 00:06:24
Finally bought a copy of Vista/64 today. First Python experience:
C:\Python25>python
Python 2.5.2 (r252:60911, Feb 21 2008, 13:17:27) [MSC v.1400 64 bit (AMD64)]
on win32
Type "help", "copyright", "credits" or
"license" for more information.
>>> import sys
>>> sys.platform
'win32'
>>>
Sigh. And then,
>>> import ctypes
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named ctypes
>>>
Um, should Python even be distributed as version "2.5.2" on this
platform if parts of the standard library are missing?
(Oh, and Vista is pretty, except when the "Press this button to keep doing
what you're doing" dialog pops up, because it always seems to blank the
screen first -- possibly disabling Aero temporarily?).
Compiling for G3 on OS X 10.5
2008-04-18 00:03:46
It took me a long time to figure this out. By default gcc on Leopard compiles
for OS X 10.5 only. When cross-compiling to PowerPC, the default target is
actually certain G4 models. The magic options for G3's and OS X 10.3.9 (it looks
like you can't compile for earlier versions any more) and later:
-arch ppc
-isysroot /Developer/SDKs/MacOSX10.4u.sdk
-mmacosx-version-min=10.3.9
-force_cpusubtype_ALL
(both linker and compiler). Use
otool -hv xyz.dylib
to check that a Mach-O file is for the target you expect ("ppc" not
"ppc7740" etc), and
lipo -info xyz.dylib
to check the contents of a universal binary.
pyglet download statistics
2008-03-23 22:44:21
I felt charty this evening, and this is what happened:
That's a breakdown by release and distribution of pyglet, from 1.0 alpha 1
through to 1.1 alpha 1 (alpha 2, released hours ago, doesn't yet rate on this
chart).
Interesting to note: the eggs are popular for release, but not development. The
only reason they're featured in 1.0 alpha 1 is that they were actually linked
from the download page then. (Now people are only likely to grab an egg if
they're using easy_install from the command line).
The Windows installer is quite the popular, which makes me glad I spent so much
time on it. (I'm not making installers available for 1.1 alpha releases).
Here are the download stats for the packages including documentation/examples.
Looks to me like the number of developers isn't really increasing, but perhaps
those developers are testing on more machines, and perhaps there are some runtime
installations being made on non-developer machines. Or maybe there are more
developers but they're happy to use old or online documentation.
There are currently 271 pyglet-users members (or 269, depending on which counter
on the same page you read).
Alex writes:
Well, this was still causing unnamed exceptions to get dumped to stderr occasionally. (Unnamed presumably because the traceback and exception machinery had been collected by the time it got handled). I've replaced the above with an atexit handler that notifies and joins all daemon threads.