John Hunter wrote: > On Thu, May 21, 2009 at 10:08 PM, Jae-Joon Lee <lee.j.j...@gmail.com> wrote: > > >> 2) Axes.frame >> Is it okay to simply drop this attribute? Any code that access this >> attribute will raise an exception. For example, some of my code in >> mpl_toolkits.axes_grid access this attribute, although a fix would be >> very trivial. >> > > We can drop it - there never was a documented reference to it, no > public method, etc, so it is safely considered mostly "internal > code", and in the global scheme is comparatively new code (and on a > quick grepping did not see any examples using it in the pylab_examples > or api dirs). I don't think it will impact many users, and anyone who > was trying to manipulate the frame directly can easily update their > code. We should just have a little transition cheatsheet in the > API_CHANGES section describing the removal. > > We *could* override getattr and raise a suitable warning pointing to > the spine docs, if people think that is needed, but overriding getattr > often leads to unintentional bugs. > Based on Jae-Joon's comment, I was thinking of making .frame a property that raised an Error describing to get .spines instead... That avoids the getattr issues, but I think depends on Artist being a new style class.
(Thanks to all for the responses... I'm acting on them and will incorporate most or all of the suggestions.) -Andrew ------------------------------------------------------------------------------ Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
