I'm animating a Circle patch with a varying center and radius, and I noticed that changing the ``radius`` attribute has no effect on the patch. Currently, ``radius`` is only used to instantiate an Ellipse object, but updating radius has no effect (i.e. redrawing the patch doesn't use the new radius). I've included a patch to add this feature. Also included in the patch is a small fix to one of the UI examples (sorry for included a completely unrelated patch but the fix seemed to small for a separate email). BTW, I'm using a property idiom from: http://code.activestate.com/recipes/205183/ . I thought that this approach was better than polluting the namespace with getters and setters, especially since this would differ from the way the Ellipse class uses ``width`` and ``height`` attributes. Cheers, -Tony =================================================================== --- lib/matplotlib/patches.py (revision 7128) +++ lib/matplotlib/patches.py (working copy) @@ -1131,6 +1131,14 @@ self.radius = radius Ellipse.__init__(self, xy, radius*2, radius*2, **kwargs) __init__.__doc__ = cbook.dedent(__init__.__doc__) % artist.kwdocd + + def radius(): + def fget(self): + return self.width / 2. + def fset(self, radius): + self.width = self.height = 2 * radius + return locals() + radius = property(**radius()) class Arc(Ellipse): """ Index: examples/user_interfaces/embedding_in_wx3.py =================================================================== --- examples/user_interfaces/embedding_in_wx3.py (revision 7128) +++ examples/user_interfaces/embedding_in_wx3.py (working copy) @@ -147,7 +147,7 @@ return True def OnBang(self,event): - bang_count = XRCCTRL(self.frame,"bang_count") + bang_count = xrc.XRCCTRL(self.frame,"bang_count") bangs = bang_count.GetValue() bangs = int(bangs)+1 bang_count.SetValue(str(bangs))
On Thu, May 21, 2009 at 12:35 PM, Tony S Yu <to...@mi...> wrote: > I'm animating a Circle patch with a varying center and radius, and I noticed > that changing the ``radius`` attribute has no effect on the patch. > Currently, ``radius`` is only used to instantiate an Ellipse object, but > updating radius has no effect (i.e. redrawing the patch doesn't use the new > radius). > I've included a patch to add this feature. Also included in the patch is a > small fix to one of the UI examples (sorry for included a completely > unrelated patch but the fix seemed to small for a separate email). > BTW, I'm using a property idiom > from: http://code.activestate.com/recipes/205183/. I thought that this > approach was better than polluting the namespace with getters and setters, > especially since this would differ from the way the Ellipse class uses > ``width`` and ``height`` attributes. Thanks Tony -- I committed this with a change. The mpl getters and setters, as well as the ACCEPTS line, are used in the object introspection and doc building, so the way to add a property like radius is: def set_radius(self, radius): """ Set the radius of the circle ACCEPTS: float """ self.width = self.height = 2 * radius def get_radius(self): 'return the radius of the circle' return self.width / 2. radius = property(get_radius, set_radius) but as I look through patches, I notice there are a number of places (eg RegularPolygon) where hidden methods w/o docstrings are used. I assume Michael wrote most of these in the transforms refactorring. Was this a conscious decision to hide them from the doc proprty introspection mechanism?
> but as I look through patches, I notice there are a number of places > (eg RegularPolygon) where hidden methods w/o docstrings are used. I > assume Michael wrote most of these in the transforms refactorring. > Was this a conscious decision to hide them from the doc proprty > introspection mechanism? > I don't think so. IIRC, most of what are now properties were raw attributes at one time, and the hidden methods was just to avoid adding more things to the public namespace. But I don't see any compelling reason they couldn't be public. Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA