M
mathieu
Hi there,
I am currently involved in managing a large python/c++ project
(using swig to automagically wrap c++ code to python). So far my
current experience was that python was a second class citizen and
extremely little python code was written and everything seemed to
work.
Now this is the contrary, large portion of code are written python
with a few expection of c++ code for core algorithms. So as you might
have guess I am coming with a c++ background into the python world.
Let's consider the following layout for project 'A':
A/
moduleA.py
B/
moduleB.py
C/
moduleC.py
module1.cxx
module1.h
module1.i
A-binary-module-gcc43/
_module1.so
module1.py
I have the current questions (I guess it's all about convention):
Q1. How should I import module1 (a c++ module that is compiled/wrap
into python) ? Because I have multiple compilers, I have a binary
directory per compiler. My guess was that PYTHONPATH should contain
the toplevel project *source* directory and the toplevel project
*binary* directory.
Possible answers:
A1. 'import module1'...well in that case I should really make sure
that noone ever tries to create a directory names module1 in directory
A/ otherwise 'import module1' statement is changing meaning.
A2. 'import A-binary-module-gcc43.module1' ... well this is safer and
would avoid namespace collision but the python code becomes dependent
(implicitely) of a compiler.
A3. Leave the module1 where it belong : in A/B/C subdirectory ... in
this case I need to have a source directory per compiler, which means
I need either some subttle trick with symlinks (lndir) or be ready to
have out of sync projects.
Q2. How do I import moduleA & moduleB ? Those are a simple python
modules that are located in A/. Behavior should be symmetric.
A1.
'from A import moduleA'
'from A.B import moduleB'
A2.
'from A import moduleA'
'from B import moduleB'
A3.
'import moduleA'
'import moduleB'
Basically A1 to A3 are organized in complexity of PYTHONPATH. A1 is
great because importing a moduleD in the future will just works
(PYTHONPATH is unchanged). A2 & A3 make the layout of the project
impact on the PYTHONPATH.
Thanks
-Mathieu
I am currently involved in managing a large python/c++ project
(using swig to automagically wrap c++ code to python). So far my
current experience was that python was a second class citizen and
extremely little python code was written and everything seemed to
work.
Now this is the contrary, large portion of code are written python
with a few expection of c++ code for core algorithms. So as you might
have guess I am coming with a c++ background into the python world.
Let's consider the following layout for project 'A':
A/
moduleA.py
B/
moduleB.py
C/
moduleC.py
module1.cxx
module1.h
module1.i
A-binary-module-gcc43/
_module1.so
module1.py
I have the current questions (I guess it's all about convention):
Q1. How should I import module1 (a c++ module that is compiled/wrap
into python) ? Because I have multiple compilers, I have a binary
directory per compiler. My guess was that PYTHONPATH should contain
the toplevel project *source* directory and the toplevel project
*binary* directory.
Possible answers:
A1. 'import module1'...well in that case I should really make sure
that noone ever tries to create a directory names module1 in directory
A/ otherwise 'import module1' statement is changing meaning.
A2. 'import A-binary-module-gcc43.module1' ... well this is safer and
would avoid namespace collision but the python code becomes dependent
(implicitely) of a compiler.
A3. Leave the module1 where it belong : in A/B/C subdirectory ... in
this case I need to have a source directory per compiler, which means
I need either some subttle trick with symlinks (lndir) or be ready to
have out of sync projects.
Q2. How do I import moduleA & moduleB ? Those are a simple python
modules that are located in A/. Behavior should be symmetric.
A1.
'from A import moduleA'
'from A.B import moduleB'
A2.
'from A import moduleA'
'from B import moduleB'
A3.
'import moduleA'
'import moduleB'
Basically A1 to A3 are organized in complexity of PYTHONPATH. A1 is
great because importing a moduleD in the future will just works
(PYTHONPATH is unchanged). A2 & A3 make the layout of the project
impact on the PYTHONPATH.
Thanks
-Mathieu