Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Added axes inversion to cla() #8455

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 14 commits into from
Apr 16, 2017
Merged

Added axes inversion to cla() #8455

merged 14 commits into from
Apr 16, 2017

Conversation

jrmlhermitte
Copy link
Contributor

Continuation of #5450
When calling cla(), axes inversion should be cleared (if any).

(I rebased the PR and could not figure out how to re-open once this was done, github won't let me)

self.set_zlim(0, 1)
except TypeError:
pass
except AttributeError:
Copy link
Contributor Author

@jrmlhermitte jrmlhermitte Apr 10, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The AttributeError is ignored because calling set_zlim activates a callback which handles other stuff when the zlim changes (not familiar with it). I am guessing that when the axes are first created this callback doesn't exist so it is safe to do? Another option is set_zlim(0,1,emit=False) but then this always ignores the callback.

Does @efiring know about this code? I'm happy to dig deeper when I have more time but honestly I am not very familiar with this code as of now, so I'm flagging this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you include the traceback? I am the one probably the most familiar with it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's line 737 of mplot3d/axes3d.py:

E           AttributeError: 'Axes3DSubplot' object has no attribute 'callbacks'
 
mplot3d/axes3d.py:737: AttributeError

You can find the longer version here

thanks!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I see what is happening. This is happening during the Axes3D constructor. It is calling the base class constructor, which calls self.cla(), which triggers the Axes3D.cla(). So, the question is, why isn't it choking first on self.set_xlim(0, 1)? Wouldn't it have hit that one first? I wonder what is still different between the base class calls and the Axes3D calls?

I'll see if I have some time later today to investigate further.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Axes3D.cla() method is setting up the zaxis before calling the 2D version of cla(). This used to be fine, but the 2D version is what creates self.callbacks. The 2D version of cla() used to be quite simple. I am rather surprised at how complicated it has become since I last looked at it.

IIRC, simply moving the 2D's cla() to the top of the call for the 3D cla() would not work, as the axis setting step messes up some of the stuff set later in the method. We can give it a try, but we might need to refactor the 2D cla() into multiple sub-parts that can be called from the 3D cla().

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, I placed the 2D cla() at top, the mplot3d tests ran fine. Hopefully Travis won't complain.

yes it looks very long. I assume things like checks for shared axes are not relevant to mplot3d?
thanks for walking me through this!

@efiring
Copy link
Member

efiring commented Apr 11, 2017 via email

@jrmlhermitte
Copy link
Contributor Author

rebased

@WeatherGod
Copy link
Member

The failed test isn't a known flakey test, but it is odd that it failed only for py2.7. I restarted it to see if it is repeatable.

With respect to shared axes, I have tried supporting it, but never tested it. Again, this is something where a refactored 2D cla() would help, as it would make sense to have helper functions that can be used for each axis, so the 3D axes can just simply add its call for the z axis.

@jrmlhermitte
Copy link
Contributor Author

thanks, looks like it works now. So by refactoring, I assume you mean breaking up cla into submethods, like _cla_shared_axes() etc?
We could give it a shot here while we're at it since this PR isn't a pressing matter (as this will likely involve a longer discussion), and this could eventually get lost.
I could look into it more as well as well. I'm not very familiar with Axes3D but I'm interested in using/playing around with it. Thanks again.

@WeatherGod
Copy link
Member

Yes, that's pretty much what I would envision for refactoring cla(). However, it really is out of scope for this PR. I would suggest starting a new PR for that effort so we can at least gain this benefit sooner rather than later. I have seen PRs languish because of scope-creep.

@jrmlhermitte
Copy link
Contributor Author

sounds good. I can work on submitting it by tomorrow evening; of course it won't be complete. It's on my calendar so it won't be forgotten.

I guess we need a second person to review this, @tacaswell ?

thanks for the support @WeatherGod

@WeatherGod
Copy link
Member

We are going to need a rebase here, but hold off a second on that until the questions in #8474 gets resolved.

@jrmlhermitte
Copy link
Contributor Author

ok, waiting. could you ping when it's merged? thanks!

@@ -1082,6 +1082,7 @@ def cla(self):
# Disabling mouse interaction might have been needed a long
# time ago, but I can't find a reason for it now - BVR (2012-03)
#self.disable_mouse_rotation()
Axes.cla(self)
Copy link
Contributor Author

@jrmlhermitte jrmlhermitte Apr 14, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@WeatherGod , curious (but not so important) question. Any reason why we're not using super(Axes3D, self).cla()? Since I'm on this line I could change to the newer method. (But I guess we shouldn't care unless we get into MRO details)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I once tried super-fying Axes3D (about 3 years ago). Some weird bugs started happening, so I dropped it. At the time, I was highly inexperienced with super(), so I might have been doing it wrong.

I am a firm believer in keeping PRs orthogonal. If you want to take a crack at super-fying Axes3D, you are more than welcome to try, but do so in a separate PR.

Copy link
Contributor Author

@jrmlhermitte jrmlhermitte Apr 14, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've battled with super quite a bit. If there is a bug, it usually has to do with Method Resolution Order (MRO) (I hope...). I think you know that already, but writing it in case anyone else is reading.

But that's something you need to worry about only when a class inherits from multiple parents. Multiple inheritance complicates things, if you just try to think about how you would do it if you had to using only super, you quickly see it's not that simple (and some convention must be chosen).

Also, I'm not sure if MRO changed from python 2x to 3x. I'll do some reading and see if it's worth doing. So I'll give it a shot (and keep it simple), and hope your bugs were to do with MRO...

PS : I think you know all this... but I'm not 100% sure. I remember this was a frustrating thing for me when I was first using multiple inheritance, but it ended up working nicely. So I figured it was worth a small discussion here.

@WeatherGod
Copy link
Member

#8474 is now merged, so you can rebase now.
The problem I had with super() probably wasn't MRO-related because there wasn't any multiple inheritance. I think I was just getting overzealous, putting super's where there shouldn't have been. I am not sure.

@jrmlhermitte
Copy link
Contributor Author

ok great. rebased. yeah, I took a look at it after, noticed there's no multiple inheritance. We can give it a shot and see how it works and tests later. thanks for the support!

Copy link
Member

@WeatherGod WeatherGod left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good now. We will see how Travis likes it in a moment.

@jrmlhermitte
Copy link
Contributor Author

jrmlhermitte commented Apr 14, 2017

ok great. i took a look. maybe error could have come from trying to super unbound methods, things like:

get_xlim3d.__doc__ = maxes.Axes.get_xlim.__doc__

Anyway, we'll see what Travis says. I'm having trouble getting tests to work on my local machine (some conflict between packages, I can fix it but I also have other things to do).

thanks for support!

@jrmlhermitte
Copy link
Contributor Author

Appveyor failed:

def snap(self):
        f = self.tmpfile
>       f.seek(0)
E       OSError: [Errno 9] Bad file descriptor

any idea what it is?

@WeatherGod WeatherGod merged commit 7ce91c6 into matplotlib:master Apr 16, 2017
@WeatherGod
Copy link
Member

no clue, but everything looked fine now.

@jrmlhermitte
Copy link
Contributor Author

note: I haven't forgotten cleaning up cla but it seems separating the shared axes may require slightly more thinking. Need to read more when I have time.
(If someone else wants to do it, they're more than welcome, I just don't want to let this idea die)

@tacaswell
Copy link
Member

Thanks @ordirules !

@QuLogic QuLogic added this to the v2.1 milestone Aug 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants