On 06/23/2011 10:53 AM, John Hunter wrote:
> On Thu, Jun 23, 2011 at 3:11 PM, Michael Droettboom<md...@stsci.edu> wrote:
>> 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.
>
> CallbackRegistry.signals is a "public" attribute, so is there anything
> preventing you Ben from just doing
>
> self.callbacks.signals.add('zlim_changed')
>
> 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.)
Eric
>
> JDH
>
> ------------------------------------------------------------------------------
> 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
------------------------------------------------------------------------------
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
