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