I read the PEP8 and the "importing Python Modules" article. However,
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.dateti me gets on my nerves though.
just my .02
Eric
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.
importing modules.
>
I'm showing what I used in my current project, and will accept your
advices on how I should change them.
import module
>
and then use
>
module.MyClass
>
( in case of a flat module)
>
or
>
from package.subpack age import module
>
and then use
>
module.MyClass
>
(( for a package/subpackage structure ))
>
and then use
>
module.MyClass
>
( in case of a flat module)
>
or
>
from package.subpack age import module
>
and then use
>
module.MyClass
>
(( for a package/subpackage structure ))
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.dateti me gets on my nerves though.
just my .02
Eric