We already check the pygtk version by using gtk.pygtk_version.
pygtk.require() is more of a migration tool to help people move from
pygtk 1.0 to 2.0 when they still have both versions installed on the
same machine, and for some reason pygtk 1.0 is given preference in

I searched and to find wx.__version__ but
did not find it. So does that mean the wx backend does not need to use
version checking?


Send instant messages to your online friends


On Fri, 2005-07-15 at 20:28 -0700, > wrote:
> I'm not familiar with pygtk.require(), but if it's anything like
> 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 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

I searched and to find wx.__version__ but
did not find it. So does that mean the wx backend does not need to use
version checking? uses the new wx namespace, which only works with
wx version 2.4 and higher. This block in

   import wx
   backend_version = wx.VERSION_STRING
   print >>sys.stderr, '...'

is therefore an effective version filter. I suppose we could
eventually _use_ the value in backend_version.


We have several users that routinely plot data sets that "wrap" around an axis. For example:

- An angle data set that is angle as a function of time. The y axis would be from 0 to 360.

- Any quantity that is a function of hour of the data. The X axis would go from 0 to 24.

In both of these cases they want to create a line plot but they don't want to have the extra line that shoots across the plot when the data wraps. For example, assume you have the angle data set like this:

import pylab as p

x = [ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 ]
y = []
for i in x:
    y.append( ( 23 + 75*i ) % 360 )

p.plot( x, y )
p.ylim( [ 0, 360 ] )

It would be nice if this data could somehow be automatically transformed to wrap correctly. Ideally, two extra points are inserted for every "wrapping" that are linearly interpolated to fall directly on the axis bounds. So the correct plot would look like this (this is terrible way to generate it but at least you can see what it should look like):

x1 = [ 0, 1, 2, 3, 4, 4.507 ]
x2 = [ 4.507, 5, 6, 7, 8, 9 ]
y1, y2 = [], []

for i in x1:
    y1.append( ( 23 + 75*i ) )

for i in x2:
    y2.append( ( 23 + 75*i ) %360 )

p.plot( x1, y1 )
p.plot( x2, y2 )
p.ylim( [ 0, 360 ] )

In ideal world it would be nice if this could be done automatically. Of course this does require some hueristic checking to decide if a point is actually crossing the wrap around value or actually moving away from the previous point. Does anyone have any thoughts on this or has anyone set up something like this before?