matplotlib-devel Mailing List for matplotlib

Christopher Barker wrote:
> The diskimage is usually built for the python binary supplied by 
> python.org -- that is what the message means by the "system version". I 
> tried to submit a patch to change that message a year or two ago, but I 
> guess it never got applied -- maybe I'll try again.
I took a look at the source for the latest bdist_mpkg -- it looks like 
it should now give a message like:
"This package requires MacPython to be installed"
though It's all a bit complicated -- did whoever built the dmg use the 
latest bdist_mpkg?
But maybe should still do:
> A note to developers/distributors:
> 
> Robin Dunn figured out a way to install a binary wxPython that will work 
> with both the Apple and the python.org binaries. What it does it put it 
> in /usr/local, and then put a pth file in both of the pythons so that it 
> can be found. A bit of a hack, but it works, and I've never heard anyone 
> have a problem with it.
> 
> Perhaps we should do the same thing with MPL -- I'm sure he'd be glad to 
> share his scripts for building it.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

John Hunter wrote:
> On Tue, Dec 1, 2009 at 6:21 PM, Eric Firing <ef...@ha...> wrote:
>> This is easy to fix by using the key kwarg (added in python 2.4) of the
>> sort method, because python uses a stable sort. It looks like it only
>> needs to be fixed in Axes.draw, because Figure.draw has never paid any
>> attention to zorder anyway. I'll do it now.
> 
> It does now in svn HEAD -- I just added this yesterday.
Yes, I saw that after I sent the first message, so I stabilized the sort 
 in Figure.draw also.
Eric

On Tue, Dec 1, 2009 at 6:21 PM, Eric Firing <ef...@ha...> wrote:
> This is easy to fix by using the key kwarg (added in python 2.4) of the
> sort method, because python uses a stable sort. It looks like it only
> needs to be fixed in Axes.draw, because Figure.draw has never paid any
> attention to zorder anyway. I'll do it now.
It does now in svn HEAD -- I just added this yesterday.
JDH

James Evans wrote:
> All,
> 
> I have been looking at some of the recent z-order changes and have found an issue that breaks previous behavior. Previously when
> items were added to a Figure or an Axes with the same z-order value, they were rendered in order of when they were added, so that
> the first one added is 'underneath' the others and the last one added is rendered 'over' all the other items of the same z-order
> value. This no longer is the case. The following snippet of code demonstrates the problem:
> 
> #===============================================================
> class ZSortClass( object ):
> def __init__( self, name, zorder = 0 ):
> self.name = name
> self.zorder = zorder
> def doit( self ):
> print "z-order [%s] = %s" % (self.name, self.zorder)
> 
> # Instantiate out of order to prove a point
> a = ZSortClass( 'a', 0 )
> c = ZSortClass( 'c', 0 )
> b = ZSortClass( 'b', 0 )
> 
> all = [ a, b, c ]
> dsu = [ (x.zorder, x.doit, x.name) for x in all ]
> 
> print dsu
> dsu.sort()
> print dsu
> #===============================================================
> 
> All three instances have the same 'zorder' value, which causes the sort command to resort to sorting on the memory address. This
> can change from run to run. In simple cases the memory addresses typically increase in order of instantiation, but in larger blocks
> of code, python can perform garbage collection at any time and this would no longer hold true, and cause the effect to appear random
> (This is also affecting the rendering of filled continents in basemap). I couldn't think of an easy solution without making some
> intrusive changes to what is already in place, so I thought that I'd post my findings for further discussion.
> 
This is easy to fix by using the key kwarg (added in python 2.4) of the 
sort method, because python uses a stable sort. It looks like it only 
needs to be fixed in Axes.draw, because Figure.draw has never paid any 
attention to zorder anyway. I'll do it now.
Eric
> --James Evans
> 
> 
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing. 
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

James Evans wrote:
> All,
> 
> I have been looking at some of the recent z-order changes and have found an issue that breaks previous behavior. Previously when
> items were added to a Figure or an Axes with the same z-order value, they were rendered in order of when they were added, so that
> the first one added is 'underneath' the others and the last one added is rendered 'over' all the other items of the same z-order
> value. This no longer is the case. The following snippet of code demonstrates the problem:
> 
> #===============================================================
> class ZSortClass( object ):
> def __init__( self, name, zorder = 0 ):
> self.name = name
> self.zorder = zorder
> def doit( self ):
> print "z-order [%s] = %s" % (self.name, self.zorder)
> 
> # Instantiate out of order to prove a point
> a = ZSortClass( 'a', 0 )
> c = ZSortClass( 'c', 0 )
> b = ZSortClass( 'b', 0 )
> 
> all = [ a, b, c ]
> dsu = [ (x.zorder, x.doit, x.name) for x in all ]
> 
> print dsu
> dsu.sort()
> print dsu
> #===============================================================
> 
> All three instances have the same 'zorder' value, which causes the sort command to resort to sorting on the memory address. This
> can change from run to run. In simple cases the memory addresses typically increase in order of instantiation, but in larger blocks
> of code, python can perform garbage collection at any time and this would no longer hold true, and cause the effect to appear random
> (This is also affecting the rendering of filled continents in basemap). I couldn't think of an easy solution without making some
> intrusive changes to what is already in place, so I thought that I'd post my findings for further discussion.
> 
Try svn 8000. I think it fixes the problem in Axes and Figure.
Eric