On Thu, Jun 23, 2011 at 6:55 PM, Benjamin Root <ben.root@...> wrote:
> On Thu, Jun 23, 2011 at 4:29 PM, Eric Firing <efiring@...> wrote:
>> On 06/23/2011 10:53 AM, John Hunter wrote:
>> > On Thu, Jun 23, 2011 at 3:11 PM, Michael Droettboom<mdroe@...>
>> >> On 06/23/2011 03:49 PM, Benjamin Root wrote:
>> >> Hello all,
>> >> I am working to make mplot3d feature-parity with regular axes objects.
>> >> have come across a possible design flaw with the CallbackRegistry.
>> >> Many of the Axes3D methods are merely wrappers around Axes methods
>> >> it do the work for x and y axis and then let Axes3D do the same for the
>> >> axis. In Axes.cla(), self.callbacks gets a CallbackRegistry of signals
>> >> named "xlim_changed" and "ylim_changed". However, once that is set, it
>> >> not appear to be a way for me to add another signal of "zlim_changed"
>> >> Axes3D.cla(). I could replace self.callbacks with a new
>> >> but since there is a lot of interveaning code between that first
>> >> initialization of self.callbacks and coming back out of Axes.cla(), I
>> >> 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
>> >> we should move towards the use of a dictionary of axis objects and make
>> >> functions more agnostic to the number of axis?
>> >> I don't know if there is a way around it as the code currently stands.
>> >> 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
>> >> begin with. It seems to me it comes from a history of callback
>> >> classes I've seen in more static languages (such as libsigc++). We
>> >> just as easily create new signal types on the fly as they are
>> >> You lose some error checking, I suppose, if the caller and receiver
>> >> 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.)
> I am willing to go with whatever makes everyone happy. I have a limited
> amount of time, and my goal with the feature-parity branch (found here:
> https://github.com/WeatherGod/matplotlib/tree/mplot3d/consistency ) is to
> get a z-version of every single axis-related function into Axes3D, and make
> sure that most other functions that operate on arbitrary axis are capable of
> acting on the z-axis.
> However, I do not intend to make sure that everything works (only that
> there are no regressions). For example, setting axis label properties
> ('right', 'left', etc.) make little sense in the current context, and
> working with minor ticks do nothing in mplot3d. The idea is that if the
> added functions work, then that is good news. If the added functions do not
> work, then that can be a bug report.
> Therefore, anything that gets me to that goal would be fine. Heck, doing
> nothing about this might also work because there never was a callback for
> zlim_changed before, so not having it now will be no loss of function.
> Sorry for rambling,
> Ben Root
I put up a pull request for adding the method "add_signal" to the
CallbackRegistry here: https://github.com/matplotlib/matplotlib/pull/381