Could you move the self.active and ignore logic up to the Widget base-class? I think that would be a more-general solution (and remove duplicate code).

If you are feeling ambitious, making sure that all of the sub-classes make proper use of super in the ignore calls is also probably a good thing to do.

Done. Moved all the active logic up to the Widget class. And removed the basic ignore functions from the subclasses.

Great.

I am a bit wary of the class level attribute which it silently made an instance attribute when you assign to it, but do anything about that until someone else weighs in.

attn @efiring @mdboom @blink1073

also attn @WeatherGod

IMO MultiCursor should subclass AxesWidget and leave Widget alone.

IMO MultiCursor should subclass AxesWidget and leave Widget alone.

That was my initial thoughts as well. But the AxesWidget takes in only single axis and all the child classes only require one so this would be the odd one out. It would also require modifications in all the subclasses of AxesWidget to check type; more ambition! Or perhaps for the single axes case make a single element tuple? But still requires modification to the subclasses.

I was in the process of typing out what @JayP16 said.

@tacaswell, you are referring to the _active attribute? I don't see any problem with this. It seems to me that this idiom makes the code more compact and makes it easier to see what the attributes are. What is it that makes you wary of it?

I have to agree with @tacaswell, class-level attributes turned into
instance attributes hurts my brain

On Tue, Mar 17, 2015 at 5:05 PM, Eric Firing [email protected]
wrote:

@tacaswell https://github.com/tacaswell, you are referring to the
_active attribute? I don't see any problem with this. It seems to me that
this idiom makes the code more compact and makes it easier to see what the
attributes are. What is it that makes you wary of it?

—
Reply to this email directly or view it on GitHub
#4225 (comment)
.

oh, wow... I never noticed that there were those other class-level attributes! That is unfortunate, and I now need an excedrin.

@efiring Yes. It is is part as Ben says a source of headaches/confusion. If seems like a nice way to do default state, but it might open up a can of worms with mutable values (which _active is not). In general any prospect of unintentionally shared state makes we wary.

@WeatherGod Why? I still don't understand the problem. Does this idiom introduce some risk? Is it any harder to understand than, say, properties? It seems straightforward to me, and something that can enhance rather than reduce readability. I think it is quite common. It is similar to the situation where module-level variables turn into local variables via assignment in a function. That's actually something I try to avoid, but in the case of classes, it seems natural to me.

do class-level attributes get inherited upon subclassing? I thought they didn't.

@tacaswell, OK, so it requires a bit of care, to avoid mutable variables.

I was just looking at http://ioam.github.io/param/index.html, which depends on this type of behavior, including the inheritance. I think traitlets also use this idiom of class-level initialization. I need to look.

Those are a bit different though as they are using meta-class magic to turn the class level attributes into instance level properties, right?

At least in params, the conversion into instance attributes happens only when a value is changed, so it is very much like the simple case. I don't know how traitlets handles them.

It looks like HasTraits initialization causes immediate instance-level initialization of all Traits, so this is handled differently than in params.

Any suggestions on what should be done? It would be problematic if it were mutable; which _active is not, like @tacaswell mentioned. Do we want a initialize method in widgets; can we see a use for it in the future?

Sorry, this PR discussion went off on a tangent (part of a rolling conversation @efiring and I are having). Eric convinced me that it is fine as implemented.

Only other comment is that it might be worth starting the deprecation process on the get/set_active methods in favor of the just using the property, but that is probably out of scope for this PR.

Can you also add an entry into https://github.com/matplotlib/matplotlib/tree/master/doc/users/whats_new It should be documented that all Widget sub-classes now have these functions.

ping @JayP16 re whats_new entry.

Sorry for the delay. It's been created. :)

@JayP16 Thank you!