On 09/01/2010 07:57 AM, Thomas Robitaille wrote: >>>> I have submitted a ticket: >>>> https://sourceforge.net/tracker/?group_id=80706&atid=560720 >>> >>> The obvious fix would be to change from patch.fill to >>> patch.get_fill(). However, I'm curious how this code got broken. >> >> I broke it here: >> http://currents.soest.hawaii.edu/hgstage/hgwebdir.cgi/mpl_hg/diff/799df584a8df/matplotlib/lib/matplotlib/patches.py >> >> The safest way to fix it--that is, preserving the old behavior of >> patch.fill--would be to make it a property. I can do that later today or >> tomorrow, or you can go ahead with it. It would be something of an >> inconsistency, in that for partly historical reasons mpl is based on an >> endless procession of getters and setters, but I don't think it would do any >> harm, and it does preserve the earlier API. At the same time, it would be >> OK to use get_fill in the PatchCollection--it will work, and it is more >> consistent with typical mpl usage. So, I think the best fix is to make both >> changes, with a comment in patches.py as to why fill is a property. > > I was wondering whether it would be possible at least for now to implement > the get_fill() fix in PatchCollection? One of the packages I develop > (http://aplpy.sourceforge.net/) depends on match_original, and recent svn > versions of matplotlib are unusable because of this. >
I broke it, so I fixed it: maintenance branch 8673, trunk 8674. Sorry for the delay. Eric ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
