Updating Circle.radius has no effect (+minor example fix)

Development matplotlib-devel
1

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, radius2, radius2, **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))

2

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?

···

On Thu, May 21, 2009 at 12:35 PM, Tony S Yu <tonyyu@...608...> 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: A tidy property idiom « Python recipes « ActiveState Code. 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.

3

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