Clean termination of daemon Python threads
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:
.... do work ...
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
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):
Outputs 'out_annotype/test.py' with:
def foo(bar, baz):
# [annotype] bar: int
# [annotype] baz: str, int
Hopefully useful for discovering usage of undocumented APIs.
Python, meet Vista/64
Finally bought a copy of Vista/64 today. First Python experience:
Python 2.5.2 (r252:60911, Feb 21 2008, 13:17:27) [MSC v.1400 64 bit (AMD64)]
Type "help", "copyright", "credits" or
"license" for more information.
>>> import sys
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
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:
(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
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
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).