471,123 Members | 887 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,123 software developers and data experts.

paths in modules

I am developing a project in Python which uses several external utilities.
For convenience, I am wrapping these accesses in a module. The problem is
that I cannot be sure where these modules are imported from, so I am
trying to figure out how to reliably execute e.g. a popen call. Example
layout:

toplevel_dir
+-main script
+-wrapper_dir
+-some_wrapper
+-utility_dir
+-some_external_utility

So in my main script, I might say:

from wrapper_dir import some_wrapper

some_wrapper.use_external_utility()
And then in some_wrapper, I would have code like:

import os

def use_external_utility():
f = os.popen('utility_dir/some_external_utility')
lines = f.readlines()
f.close()
return lines
Of course, the problem with that approach is that it fails because there
is no utility_dir in the CWD, which is actually top_level_dir. So my
question is whether there is any way to specify that specified paths are
relative to the module's directory rather than the importing file's
directory. I would really like to avoid kludging together some solution
that involves passing variables or having knowledge of where my module is
being imported from.

I am hoping that there is some simple solution to this problem that I
simply haven't found in my searches so far. If so, I will humbly accept
any ridicule that comes along with said simple solution :-).

Thanks in advance,
Brandon
Feb 22 '07 #1
5 933
On Thu, 22 Feb 2007 11:13:46 -0500, Brandon Mintern wrote:
Of course, the problem with that approach is that it fails because there
is no utility_dir in the CWD...
....and of course by CWD, I actually mean "current working directory",
which should have actually been PWD or "present working directory".
Anyway, I just wanted to clear up any confusion that might result due to
my improper terminology.
Feb 22 '07 #2
On 22 Feb, 17:13, Brandon Mintern <mint...@cse.ohio-state.eduwrote:
>
toplevel_dir
+-main script
+-wrapper_dir
+-some_wrapper
+-utility_dir
+-some_external_utility
[...]
And then in some_wrapper, I would have code like:

import os

def use_external_utility():
f = os.popen('utility_dir/some_external_utility')
lines = f.readlines()
f.close()
return lines
And you really want to refer to utility_dir relative to some_wrapper.
What you can try is to split the __file__ attribute of some_wrapper -
it's a standard attribute on imported modules - in order to refer to
the module's parent directory (which should correspond to
wrapper_dir):

parent_dir, filename = os.path.split(__file__)

Then you can join the parent directory to the path of the command:

cmd = os.path.join(parent_dir, "utility_dir", "some_external_utility")

The __file__ attribute of modules is documented here:

http://docs.python.org/ref/types.html#l2h-109

Paul

Feb 22 '07 #3
Brandon Mintern wrote:
I am developing a project in Python which uses several external utilities.
For convenience, I am wrapping these accesses in a module. The problem is
that I cannot be sure where these modules are imported from, so I am
trying to figure out how to reliably execute e.g. a popen call. Example
layout:

toplevel_dir
+-main script
+-wrapper_dir
+-some_wrapper
+-utility_dir
+-some_external_utility

So in my main script, I might say:

from wrapper_dir import some_wrapper

some_wrapper.use_external_utility()
And then in some_wrapper, I would have code like:

import os

def use_external_utility():
f = os.popen('utility_dir/some_external_utility')
lines = f.readlines()
f.close()
return lines
Of course, the problem with that approach is that it fails because there
is no utility_dir in the CWD, which is actually top_level_dir. So my
question is whether there is any way to specify that specified paths are
relative to the module's directory rather than the importing file's
directory. I would really like to avoid kludging together some solution
that involves passing variables or having knowledge of where my module is
being imported from.

I am hoping that there is some simple solution to this problem that I
simply haven't found in my searches so far. If so, I will humbly accept
any ridicule that comes along with said simple solution :-).

Thanks in advance,
Brandon
Normally this would be:

f = os.popen('./wrapper_dir/utility_dir/some_external_utility')

-Larry
Feb 22 '07 #4
On Thu, 22 Feb 2007 08:28:50 -0800, Paul Boddie wrote:
And you really want to refer to utility_dir relative to some_wrapper.
What you can try is to split the __file__ attribute of some_wrapper -
it's a standard attribute on imported modules - in order to refer to
the module's parent directory (which should correspond to
wrapper_dir):

parent_dir, filename = os.path.split(__file__)

Then you can join the parent directory to the path of the command:

cmd = os.path.join(parent_dir, "utility_dir", "some_external_utility")

The __file__ attribute of modules is documented here:

http://docs.python.org/ref/ty__file__ is the pathname of the file from
which the module was loadedpes.html#l2h-109

Paul
Thanks a lot. I was hoping for a solution like that, and it worked
perfectly for me (admittedly, in my trivial test files, but I'm sure that
the solution will extend to my actual use case).

Also, I had actually read that documentation you pointed me to, but the
language, "__file__ is the pathname of the file from which the module was
loaded" had me thinking that it was the pathname of the file doing the
loading, rather than the file being loaded. I guess I should have
actually tried it out.

Anyways, thanks for the quick response and for the clarification.
Feb 22 '07 #5
On Thu, 22 Feb 2007 10:30:59 -0600, Larry Bates wrote:
Normally this would be:

f = os.popen('./wrapper_dir/utility_dir/some_external_utility')

-Larry
Yes, but the problem with that solution is, let's say that I further
abstract the whole thing and I add a directory outside of my toplevel_dir,
which has the syntax:

from toplevel_dir.wrapper_dir import some_wrapper

some_wrapper.use_external_utility()
Now, once again, the module is broken. This is what I was trying to
avoid. At any rate, Paul's solution was exactly what I was looking for.
Feb 22 '07 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by peter walker | last post: by
reply views Thread by sashan | last post: by
2 posts views Thread by Raaijmakers, Vincent \(GE Infrastructure\) | last post: by
5 posts views Thread by Bill Davis | last post: by
6 posts views Thread by David Siroky | last post: by
5 posts views Thread by David Mathog | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.