On 06/23/2011 03:49 PM, Benjamin Root wrote:
Hello all,
I am working to make mplot3d feature-parity with regular axes
objects. I have come across a possible design flaw with the
CallbackRegistry.
Many of the Axes3D methods are merely wrappers around Axes methods
letting it do the work for x and y axis and then let Axes3D do the
same for the z axis. In Axes.cla(), self.callbacks gets a
CallbackRegistry of signals named "xlim_changed" and "ylim_changed".
However, once that is set, it does not appear to be a way for me to
add another signal of "zlim_changed" in Axes3D.cla(). I could replace
self.callbacks with a new CallbackRegistry, but since there is a lot
of interveaning code between that first initialization of
self.callbacks and coming back out of Axes.cla(), I worry that some
callbacks may have been registered by then and would get eliminated in
the process.
Is there a recommended way around this? Or maybe this is more
evidence that we should move towards the use of a dictionary of axis
objects and make Axes functions more agnostic to the number of axis?
I don't know if there is a way around it as the code currently stands.
Your proposal here:
https://github.com/matplotlib/matplotlib/issues/379
seems like one way out. Then the code that creates the CallbackRegistry
in Axes.cla() could iterate through all the axes and create a callback
type for each of them.
However, to step back from this, I've never quite understood why it was
necessary to have a fixed set of callback types in the CallbackRegistry
to begin with. It seems to me it comes from a history of callback
registry classes I've seen in more static languages (such as
libsigc++). We could just as easily create new signal types on the fly
as they are registered. You lose some error checking, I suppose, if the
caller and receiver don't agree on the names, but seems like a small
price to pay.
Mike
--
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA
------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel