On Thu, Jun 23, 2011 at 6:55 PM, Benjamin Root <ben.r...@ou.edu> wrote:
> On Thu, Jun 23, 2011 at 4:29 PM, Eric Firing <efir...@hawaii.edu> wrote:
>
>> 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
>>
>>
> 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
Ben Root
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense..
http://p.sf.net/sfu/splunk-d2d-c1
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
