Advice on the style to use in imports
Marco Bizzarri
I read the PEP8 and the "importing Python Modules" article. However,
I'm still a little confused on what should the general rules for
importing modules.
I'm showing what I used in my current project, and will accept your
advices on how I should change them.
The style is consistently the following:
from package.subpackge.module import MyClass
Is this an accepted way to write imports? According to what I
understood in articles, I don't think so.
If I understand it correctly, it should be:
import module
and then use
module.MyClass
( in case of a flat module)
or
from package.subpackage import module
and then use
module.MyClass
(( for a package/subpackage structure ))
Thank you all for your attention
Regards
Marco
--
Marco Bizzarri
http://iliveinpisa.blogspot.com/
http://notenotturne.blogspot.com/
Fredrik Lundh
> I'm showing what I used in my current project, and will accept your
> advices on how I should change them.
>
> The style is consistently the following:
>
> from package.subpackge.module import MyClass
>
> Is this an accepted way to write imports? According to what I
> understood in articles, I don't think so.
importing objects instead of the module (namespace) they live in can
cause all sorts of aliasing and dependency issues. avoid unless you
know exactly what you're doing.
</F>
Marco Bizzarri
>
> importing objects instead of the module (namespace) they live in can cause
> all sorts of aliasing and dependency issues. avoid unless you know exactly
> what you're doing.
>
> </F>
>
Thanks Fredrik; I understand that is the underlying message of your article.
I'm just confused because PEP8 seems to suggest that the from module
import Class style is acceptable; is there a big "if you know what are
doing" before, which I'm unable to see?
bearoph...@lycos.com
> I'm just confused because PEP8 seems to suggest that the from module
> import Class style is acceptable; is there a big "if you know what are
> doing" before, which I'm unable to see?
from somemodule import somename
is often acceptable IHMO, but there are some things to consider:
- you and the person that reads your code have to remember where
somename comes from. So you can do it for well known names like izip
or imap, but if you import lots of names from lots of modules, things
may become too much complex. So often it can be better to import just
the modules, and use somemodule.somename.
- somemodule.somename is longer to write and to read, and if it's
repeated many times it may worsen the program readability, making
lines of code and expressions too much long and heavy. So you have to
use your brain (this means that you may have to avoid standard
solutions). Note that you can use a compromise, shortening the module
name like this:
import somemodule as sm
Then you can use:
sm.somename
- somemodule.somename requires an extra lookup, so in long tight loops
(if you don't use Psyco) it slows down the code. This can be solved
locally, assigning a local name into a function/method (or even in
their argument list, but that's a hack to be used only once in a
while):
localname = somemodule.somename
Bye,
bearophile
Eric Wertman
> I'm still a little confused on what should the general rules for
> importing modules.
>
> advices on how I should change them.
> import module
>
> and then use
>
> module.MyClass
>
> ( in case of a flat module)
>
> or
>
> from package.subpackage import module
>
> and then use
>
> module.MyClass
>
> (( for a package/subpackage structure ))
My opinion is that this is the preffered way, generally speaking. Not
only does it avoid namespace issues as effbot pointed out, but it also
makes code easier to read later. As examples, I tend to break those
rules frequently with these :
from pprint import pprint # Because pprint.pprint is just redundant
from lxml import etree # Actually I guess this doesn't break the rule.
from datetime import datetime # This might be a bad idea... I haven't
had problems yet though. datetime.datetime gets on my nerves though.
just my .02
Eric
Marco Bizzarri
On Sat, Aug 30, 2008 at 4:04 PM, <bearoph...@lycos.com> wrote:
>
> from somemodule import somename
>
> is often acceptable IHMO, but there are some things to consider:
> - you and the person that reads your code have to remember where
> somename comes from. So you can do it for well known names like izip
> or imap, but if you import lots of names from lots of modules, things
> may become too much complex. So often it can be better to import just
> the modules, and use somemodule.somename.
Yes, that's true; but when I see that I need so many symbols from
another module, I take that as an hint that either my module is doing
too many things, and it should be splitted, or it is tightly coupled
to that module... actually, being forced to write all the imports in
that way was a tool into inspecting the dependencies in our project.
> - somemodule.somename is longer to write and to read, and if it's
> repeated many times it may worsen the program readability, making
> lines of code and expressions too much long and heavy. So you have to
> use your brain (this means that you may have to avoid standard
> solutions). Note that you can use a compromise, shortening the module
> name like this:
> import somemodule as sm
> Then you can use:
> sm.somename
it is not a problem to have special cases, as long as they are
"special"; I'm looking for more or less accepted solutions; of course
any project has some area where it is better to follow readability
over standards; I'm just trying to understand the standards, then I
will deviate from them.
I feel like I'm learning to drive: first I learn the rules, then I
learn the exceptions ;)
> - somemodule.somename requires an extra lookup, so in long tight loops
The slowdown was what in the first place made me import all the names
directly; but I'm not afraid too much from that, right now.
> (if you don't use Psyco) it slows down the code. This can be solved
> locally, assigning a local name into a function/method (or even in
> their argument list, but that's a hack to be used only once in a
> while):
> localname = somemodule.somename
>
> Bye,
> bearophile
> --
> http://mail.python.org/mailman/listinfo/python-list
>
Thanks again for sharing your thoughts with me, bearophile.
Marco Bizzarri
> http://mail.python.org/mailman/listinfo/python-list
>
Thanks Eric; your 02 cents are worthy for me ;)
Regards
Marco
Bruno Desthuilliers
> Hi all.
>
> I read the PEP8 and the "importing Python Modules" article. However,
> I'm still a little confused on what should the general rules for
> importing modules.
>
> I'm showing what I used in my current project, and will accept your
> advices on how I should change them.
>
> The style is consistently the following:
>
> from package.subpackge.module import MyClass
>
> Is this an accepted way to write imports?
Yes, BUT : it means that if package.subpackge.module.MyClass is rebound
during program execution (ie: after you imported it), your own code
won't see that change.