>>> 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. Thanks! Tom > > Eric > >> >> Eric, any ideas? SVN claims that the last change to that line was done >> by you (based on a bug *I* reported)? It apparently worked then: >> >> http://sourceforge.net/mailarchive/message.php?msg_name=487A5AE3.5070500%40gmail.com >> >> Ryan >> > ------------------------------------------------------------------------------ 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
