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
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.
CallbackRegistry.signals is a "public" attribute, so is there anything
preventing you Ben from just doing
and then connecting your desired callback?
Yes, it requires some modification to the CallbackRegistry:
def __init__(self, signals):
'*signals* is a sequence of valid signals'
self.signals = set(signals)
self.callbacks = dict([(s, dict()) for s in signals])
self._cid = 0
So adding to the set of signals is not enough. It would be easy to made an add_signal() method to take care of the two necessary steps. It would seem simpler, however, to just let the signals be added automatically as needed, as I believe Mike is suggesting.
Actually, it looks like self.signals could be replaced by a property that, upon reading, would return self.callbacks.keys(). Why use two data structures if one will do? Of course, since signals is public, that would represent API breakage--but of a rather obscure sort.
(Shooting from the hip; I haven't looked closely.)
On 06/23/2011 10:53 AM, John Hunter wrote:
On Thu, Jun 23, 2011 at 3:11 PM, Michael Droettboom<mdroe@...31...> wrote:
On 06/23/2011 03:49 PM, Benjamin Root wrote:
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.
Matplotlib-devel mailing list