pygtk.require()

I notice that pygtk.require('2.0') calls have appeared in
backend_gtk.py and backend_gdk.py

It has not appeared, its been used since matplotlib 0.53 at least,
probably forever.

I am not convinced that library code should include calls to
pygtk.require()
>
The problem is that pygtk.require() has to be called >before<
importing gtk.
>
This means that if you are using gtk then you have two choices:
> 1. never use pygtk.require()
> 2. always precede any 'import gtk' with 'import pygtk' and
> 'pygtk.require('2.0')'
I have found that 1. works pretty well and prefer not to litter code
with the pygtk.require() boiler plate.
>
Unfortunately, approach 1. falls over if you use some library that
decides to use pygtk.require().
>
In the times when I do require a specific version of pygtk then I can
always create a simple wrapper that does the pygtk require stuff.
>
Now no doubt I'm missing some subtleties as to why it is good to have
these pygtk.require() calls in matplotlib. Is there any way to make
them optional?
>
A half-way house would be to do something like this:
>
try:
    import pygtk
    if not matplotlib.FROZEN and not sys.modules.has_key('gtk'):
        pygtk.require('2.0')
except:
    print >> sys.stderr, sys.exc_info()[1]
    raise SystemExit('PyGTK version %d.%d.%d or greater is required to
run '
                     'the GTK Matplotlib backends'
                     % pygtk_version_required)
>
This code would ensure that the correct pygtk is loaded for people who
haven't already import'ed gtk without throwing an exception for those
that have loaded gtk prior to importing matplotlib.
>
The down side with this fix is that it doesn't help anyone who does
want the pygtk.require() but has made the mistake of importing gtk
first.
>
Any thoughts?
>
John

I've never liked pygtk.require(), it tries to be clever by editing your
sys.path to solve one problem, but creates other problems like you describe,
so on balance you don't gain much, if anything.

The only situation it helps with is when you have pygtk 1 and 2 installed on
the same system AND pygtk 1 is ahead of pygtk 2 in sys.path. I think that is
increasing rare nowadays.

My vote is to remove it completely.

Steve

Send instant messages to your online friends http://au.messenger.yahoo.com

···

On Thu, 2005-07-14 at 10:52 -0700, matplotlib-users-request@lists.sourceforge.net wrote:

Steve Chaplin wrote:

[Matplotlib-users] Re: pygtk.require()

I notice that pygtk.require(‘2.0’) calls have
appeared in

backend_gtk.py and backend_gdk.py

It has not appeared, its been used since matplotlib
0.53 at least,

probably forever.

oops, yes you are right.

I saw a comment in the 0.83 release notes re: pygtk require 2.0 +
assumed this was what was making my code mis-behave.

it looks like this is the change the release notes were talking about:

< pygtk_version_required = (1,99,16)

···

matplotlib-users-request@lists.sourceforge.net

I'm not familiar with pygtk.require(), but if it's anything like

wxversion.select()

Don't Get Rid of It!

No matter how hard we all try, packages are not totally backward compatible. Having a dependency without any version info in it is the road to hard to identify bugs. If matplotlib has been tested only with certain versions of pygtk, it's quite reasonable that folks get an error message if they try to run it with other versions. To do otherwise would be like having a dynamically linked app with non-version dynamic libs.

That being said, perhaps pygtk.require(), or the way it is being used, is not very well suited to this task. With wxversion, the select call must be made before any imports of wx. Thus, it should only be called in __main__. If you have a module (like matplotlib) that has been tested against certain versions, you should test for the version by checking wx.__version__, rather than calling wxversion.select(). The exception to this might be pylab for interactive use, where it is acting as the first importer of wx.

So, my suggestion is that if pygtk.require() is causing more trouble than it's worth, then figure out how to use it differently, rather than scrapping it all together.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer
                                         
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@...259...