469,962 Members | 2,328 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,962 developers. It's quick & easy.

Organizing code - import question

Hello,

I am trying to organize some of my code, and am having a little trouble with the
import logic. I find I often have something like:

MyPackage/
Part1/ # wants to use functions in Common/
__init__.py # does "from MyClass1 import MyClass1", etc,...
MyClass1.py
MyClass1a.py # depends on MyClass1
MyClass1b.py # depends on MyClass1

Part2/ # wants to use functions in Common/
__init__.py # does "from MyClass2 import MyClass2", etc,...
MyClass2.py # depends on MyClass1 also, such as containing a list of MyClass1
MyClass2a.py # depends on MyClass2
MyClass2b.py # depends on MyClass2

Common/
__init__.py # does "import fun1,fun2", etc,...
fun1.py
fun2.py

So I have some common utilities that both classes want to access, and I have two
separate class definitions, of which one depends on the other. In MyClass2.py, I
can't seem to do:

import Common.fun1

or

from Part1.MyClass1 import MyClass1
I think I am either missing some syntax/path thing, or I am thinking about the
organization in entirely the wrong way. Currently, as a hack, I am simply copying
the code from Common into the other two directories, and making a link to the Part1
directory in the Part2 so I can import it. There must be a better way, yes?
thanks,

Brian Blais

--
-----------------

bb****@bryant.edu
http://web.bryant.edu/~bblais
May 3 '07 #1
4 1243
On May 3, 8:41 am, Brian Blais <bbl...@bryant.eduwrote:
Hello,

I am trying to organize some of my code, and am having a little trouble with the
import logic. I find I often have something like:

MyPackage/
Part1/ # wants to use functions in Common/
__init__.py # does "from MyClass1 import MyClass1", etc,...
MyClass1.py
MyClass1a.py # depends on MyClass1
MyClass1b.py # depends on MyClass1

Part2/ # wants to use functions in Common/
__init__.py # does "from MyClass2 import MyClass2", etc,...
MyClass2.py # depends on MyClass1 also, such as containing a list of MyClass1
MyClass2a.py # depends on MyClass2
MyClass2b.py # depends on MyClass2

Common/
__init__.py # does "import fun1,fun2", etc,...
fun1.py
fun2.py

So I have some common utilities that both classes want to access, and I have two
separate class definitions, of which one depends on the other. In MyClass2.py, I
can't seem to do:

import Common.fun1

or

from Part1.MyClass1 import MyClass1

I think I am either missing some syntax/path thing, or I am thinking about the
organization in entirely the wrong way. Currently, as a hack, I am simply copying
the code from Common into the other two directories, and making a link to the Part1
directory in the Part2 so I can import it. There must be a better way, yes?

thanks,

Brian Blais

--
-----------------

bbl...@bryant.edu
http://web.bryant.edu/~bblais
It looks like you need __init__.py in MyPackage. Then you can import
starting with MyPackage. For example, you might use one of the
following:

import MyPackage
from MyPackage.Common import *
etc

--
Carlos Hanson

May 3 '07 #2
Carlos Hanson wrote:
It looks like you need __init__.py in MyPackage. Then you can import
starting with MyPackage. For example, you might use one of the
following:

import MyPackage
from MyPackage.Common import *
etc
that means that MyPackage must be in the sys path too? It doesn't seem like a
contained-module sees the container in any way.
bb
--
-----------------

bb****@bryant.edu
http://web.bryant.edu/~bblais
May 3 '07 #3
En Thu, 03 May 2007 12:41:00 -0300, Brian Blais <bb****@bryant.edu>
escribió:
I am trying to organize some of my code, and am having a little trouble
with the import logic. I find I often have something like:

MyPackage/
Part1/ # wants to use functions in Common/
__init__.py # does "from MyClass1 import MyClass1", etc,...
MyClass1.py
MyClass1a.py # depends on MyClass1
MyClass1b.py # depends on MyClass1

Part2/ # wants to use functions in Common/
__init__.py # does "from MyClass2 import MyClass2", etc,...
MyClass2.py # depends on MyClass1 also, such as containing a
list of MyClass1
MyClass2a.py # depends on MyClass2
MyClass2b.py # depends on MyClass2

Common/
__init__.py # does "import fun1,fun2", etc,...
fun1.py
fun2.py

So I have some common utilities that both classes want to access, and I
have two separate class definitions, of which one depends on the other.
In MyClass2.py, I can't seem to do:

import Common.fun1

or

from Part1.MyClass1 import MyClass1
To be able to do that, MyPackage should be on sys.path
If its *container* (i.e. the directory containing MyPackage, perhaps
site-packages) is already on sys.path, you could prefix all imports with
the package name: import MyPackage.Common.fun1, or from MyPackage.Part1
import MyClass1
(Dont forget the __init__.py on MyPackage, to make it a real package)

If you are using Python 2.5, you can use relative imports. Read the
"What's new" document. In MyClass2.py you could use, then: from ..Common
import fun1, or: from ..Part1.MyClass1 import MyClass1

--
Gabriel Genellina
May 4 '07 #4
On 5/3/07, Brian Blais <bb****@bryant.eduwrote:
Carlos Hanson wrote:
It looks like you need __init__.py in MyPackage. Then you can import
starting with MyPackage. For example, you might use one of the
following:

import MyPackage
from MyPackage.Common import *
etc

that means that MyPackage must be in the sys path too? It doesn't seem like a
contained-module sees the container in any way.
That is exactly right. Without being in the sys path, Python does not
know where to look to resolve the import statements.
--
Carlos Hanson
May 4 '07 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

7 posts views Thread by ToMeK | last post: by
3 posts views Thread by Jamie | last post: by
reply views Thread by netsurfer802 | last post: by
reply views Thread by Fredrik Strandberg | last post: by
12 posts views Thread by xkenneth | last post: by
5 posts views Thread by ivarnelispam | last post: by
1 post views Thread by eliben | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.