-
-
Notifications
You must be signed in to change notification settings - Fork 7.6k
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
change cbook to relative import #1637
Conversation
I'm not sure if there is a preference to using absolute vs relative imports in the mpl codebase. @mdboom - any preferences? @WeatherGod - I know you did some stuff with relative imports a while back, did we come up with a preferred standard to follow (i.e. Thanks for the fix @jakevdp. |
I haven't been part of the discussion before, but with python 2.4 support dropped, is there any reason not to use relative imports within a module? |
My preference is for absolute imports. |
@@ -216,7 +216,7 @@ | |||
from __future__ import print_function | |||
import sys, warnings | |||
|
|||
from cbook import flatten, is_string_like, exception_to_str, \ | |||
from .cbook import flatten, is_string_like, exception_to_str, \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't we have to import from future in order to do this in the 2.x series?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, relative imports are valid out-of-the-box in 2.5+.
My preference is for absolute imports (i.e. the "new" way and the default way in 3.x) as well. We have a somewhat commonly occurring problem in matplotlib, since it was a module called |
Where did you hear that absolute imports are the default way in python 3.x? I just reviewed a python 3 book by Dave Beazley where he recommends the opposite. |
This can be a bit confusing. What happens in py3k is that the default "interpretation" of an import changes from implicitly relative to implicitly absolute. With py25 and above, you gain the ability to explicitly state that an import is relative. What a project chooses to do is up to the project (and I prefer absolutes), it is just now completely unambiguous in py3k what is meant. |
The new behavior, which is the default in 2.7 and above, is turned on in older versions by saying
It's this "mode" that I was referring to and saying I preferred. What this does is turn off the "look first locally, then globally" behaviour. So a It's all confusingly named -- we want to use the "absolute import by default" behavior of the new Pythons, with the result that most of our imports become relative. |
Ah, I see. |
Personally: the former, but I wouldn't be upset if we all agreed on the latter... Just for context, it is worth reading the relevant PEP on this: http://www.python.org/dev/peps/pep-0328/#rationale-for-relative-imports |
I prefer the latter, but I wouldn't upset if we all agree on the former. In fact, I think the preferred way in matplotlib is the former. |
I'm with @NelleV on this... I don't think there's a strong objective argument either way. While relative imports make some refactorings easier, it makes others harder. Once we reach consensus, though, let's not forget to update the coding standards. |
There are other modules that have implicite relative imports which are not supported in the future (the module table for examples) that need fixing. I'll submit a PR as soon as we've decided what is the best approach here. |
On 2013/01/08 1:30 AM, Varoquaux wrote:
I agree that there seems to be no strong argument we can use to decide |
Ok, because I think we are better having some decision over none, and there is no compelling argument either way, I'm going to stick my head above the parapet and say: "Lets go with absolute imports". @mdboom as bd please feel free to trump my statement if you would prefer we fell on the other side of the knife. |
@pelson: Sure, let's go with that. It does seem to be the more common choice in the existing code base. |
Great - I changed the commit to an absolute import. This should be OK |
Thanks @jakevdp . Merging. |
Post merge brainwave: presumably we do not test pylab at all if this was not picked up by travis / the python3 migration. I think we should consider adding such a test to at least import pylab. Any thoughts? |
In the current master, the following bug is present in python 3
This PR changes
cbook
to a relative import, which works in both python 2.6+ and python 3+.