R
rocky
Import relative?
Recently for fun I've been working on a large Python program. It has
many files/modules spread over several directories/submodules.
Each module has some "demo" code at the end that I can use to run or
experiment with that module. Of course, modules often refer to others;
depending on which one, more of the code may get pulled in or not.
In this situation it has been very convenient to have do "import
relative" which is like import, but I get to specify where to start
searching from. Of course I can set sys.path, but I find that hokey.
(When I write systems administration scripts, I also generally prefer
specifying a full path name to a program, e.g. /bin/mount rather than
using PATH. Strikes me as the same issue here).
The other thing about the Python import mechanism that sometimes gets
in the way is that if there is a module imported (from the wrong place
for this context), it tacitly gets used. Within such a project I want
to specify when I want the code in this project, and if it can't find
that, then that's a failure.
I'm curious if other have the same problem and how other they deal
with this? Reading "Expert Python Programming", I see that one
solution is to install into a sandbox. But it strikes me as a little
less agile. Just as I don't enjoy issuing compile and link commands
(even if run via a Makefile), I don't want to have to issue install-
into-sandbox commands.
For concreteness here's the import code I've been using is:
http://code.google.com/p/pyimport-relative/
It is far from perfect because I just wanted to get this done and I
don't fully understand the Python modules and imp module, but for now
it gets what I want done. I will probably add some ability to top-
level package name to avoid collisions from other packages. However if
I do this, I still will probably have the program figure out the
intermediate compound names. So if I am in directory ...my-project/a/b/
c and I can say import_relative("x", "myproject") and have it import
that as "myproject.a.b.c.x". That way, if files move around and get
renamed I don't have to change any code. Also, I can probably store
somewhere in a variable "myproject".
Code that uses this can be found at http://code.google.com/p/pydbg/
Suggestions on how to improve the code are welcome; but again I don't
represent that this is done that well or that I've mastered this.
Oh, also meant to mention that in looking at say the knee code (which
looks like a translation into Python of its C code) and the C code, a
very deliberate decision was made *not* to allow filenames. So I
probably am treading where others have been and have decided not to
go. If folks are aware of threads, and discussions on this I'd be
grateful for pointers on this discussion.
Thanks.
Recently for fun I've been working on a large Python program. It has
many files/modules spread over several directories/submodules.
Each module has some "demo" code at the end that I can use to run or
experiment with that module. Of course, modules often refer to others;
depending on which one, more of the code may get pulled in or not.
In this situation it has been very convenient to have do "import
relative" which is like import, but I get to specify where to start
searching from. Of course I can set sys.path, but I find that hokey.
(When I write systems administration scripts, I also generally prefer
specifying a full path name to a program, e.g. /bin/mount rather than
using PATH. Strikes me as the same issue here).
The other thing about the Python import mechanism that sometimes gets
in the way is that if there is a module imported (from the wrong place
for this context), it tacitly gets used. Within such a project I want
to specify when I want the code in this project, and if it can't find
that, then that's a failure.
I'm curious if other have the same problem and how other they deal
with this? Reading "Expert Python Programming", I see that one
solution is to install into a sandbox. But it strikes me as a little
less agile. Just as I don't enjoy issuing compile and link commands
(even if run via a Makefile), I don't want to have to issue install-
into-sandbox commands.
For concreteness here's the import code I've been using is:
http://code.google.com/p/pyimport-relative/
It is far from perfect because I just wanted to get this done and I
don't fully understand the Python modules and imp module, but for now
it gets what I want done. I will probably add some ability to top-
level package name to avoid collisions from other packages. However if
I do this, I still will probably have the program figure out the
intermediate compound names. So if I am in directory ...my-project/a/b/
c and I can say import_relative("x", "myproject") and have it import
that as "myproject.a.b.c.x". That way, if files move around and get
renamed I don't have to change any code. Also, I can probably store
somewhere in a variable "myproject".
Code that uses this can be found at http://code.google.com/p/pydbg/
Suggestions on how to improve the code are welcome; but again I don't
represent that this is done that well or that I've mastered this.
Oh, also meant to mention that in looking at say the knee code (which
looks like a translation into Python of its C code) and the C code, a
very deliberate decision was made *not* to allow filenames. So I
probably am treading where others have been and have decided not to
go. If folks are aware of threads, and discussions on this I'd be
grateful for pointers on this discussion.
Thanks.