Why the default sys.path[0] insertion? (It breaks my code.)
Robb Shecter
rs at onsitetech.com
Thu Dec 19 19:39:40 EST 2002
I'm trying to set up a package naming scheme that seems pretty rational.
I have an application called 'mpm', and some app-independent framework
classes:
mpm # Root of code specific to this app
mpm.db # Data access code specific to this app
mpm.ui # UI code specific to this app
ui # Root of app-independent UI code
ui.image # App-independent image manipulation code
util # Root of app-independent util code
This works fine until I create the mpm.ui package. Modules in the mpm
package that have an "import ui" statement expecting to get ui, now get
mpm.ui, and so the expected objects aren't there.
Apparently this is because the script I executed is in the mpm
directory, and this becomes sys.path[0]. And this causes subpackages of
mpm to be imported as if they were top-level packages. So, two things
occur to me:
1) This behavior is inconsistent: Programmers cannot use relative
package specs in the import statement. But in this one case, the import
statement is being interpreted relatively!
2) I guess that a workaround would be either a) Make a dummy script in
the top-level directory that relays the call to the one in the
subdirectory, or b) Somehow configure my environment to to
sys.path.pop(0). I'm not sure which solution is cleaner.
This is aggravated because I like to put demo/test code into every
module so it can be executed alone. So I have a dozen
'mini-applications' which don't work.
Comments?
More information about the Python-list
mailing list