[SciPy-dev] plt

ERIC JONES ejones17 at austin.rr.com
Tue Oct 23 10:29:26 CDT 2001

Hey Jochen,

> Is there a good reason not to check whether plt is available?

Unfortunately, yes.  There are actually two reasons.  Of course, the
behavior you suggest is most desirable, so if anyone knows a way around
either of these issue, please share!

Unless your running from pyCrust or some other wxPython based shell,
gui_thread has to be imported *and* finish loading wxPython in the
background thread before any other module based on wxPython is loaded.
There is an issue with Python's import locking mechanism that makes it
impossible to have gui_thread wait for the 2nd thread to get initialized
before it returns.  Thus,

    import gui_thread
    import plt

does not guarantee that gui_thread will finish initializing wxPython before
plt gets to.  If plt gets to it first, bad things happen.  That's why you
have to import gui_thread at the beginning of a python session (or in you
startup.py) before anything else.

I do have a patch to Python for this laying around, but it was for 1.5.  I
haven't tried it on 2.1, and it hasn't seen extensive testing.  Perhaps,
I'll submit it again and hope it makes into 2.3 or so.

Some more notes on this are at:


plt is based on wxPython which is usually based on wxGTK (in Unix), which is
based on (surprise) GTK.  If a X display is not available when GTK is
started up, it immediately terminates the process.  Thus, if you attempt to
import plt from a telnet session that doesn't have a display, the Python
session exits.  Not good.

As far as I know, this behavior is deep in the bowels of either GTK or
wxGTK, and it is not currently possible to catch this behavior as an
exception instead of have it exit.

I guess we could learn this info some other way though.  Anyway to check if
an X terminal is available prior to trying to load plt?  Is checking whether
a DISPLAY environment variable exists sufficient?

see ya,


More information about the Scipy-dev mailing list