Python packages - problems, pitfalls.
bh at intevation.de
Tue Nov 6 16:17:15 CET 2001
Prabhu Ramachandran <prabhu at aero.iitm.ernet.in> writes:
> I have an application that is shipped as part of a package. I'd like
> the application to run right off the main directory or when the
> package is installed. Also lets add to the problem by saying that the
> project is under CVS and its a pain putting everything into another
> directory. Something like this:
> # app is the application that is not part of the package
If it's not part of the package, why is it in pkg_root? Put it somewhere
outside of pkg_root, make sure pkg_root is in a directory on Python's
path and everything should be fine.
> Also, irrespective of whether people have run into such problems or
> not, don't you think it makes sense for modules to be searched the way
> I had suggested earlier?? Or is there some serious issue with this.
The name search rules for packages are more or less the same as for
local variables in functions, at least when packages were introduced.
With nested scopes that similarity will be gone, though.
Anyway, you may want to search a bit through Python's history. Python
1.3 introduced the first stab a packages of modules with a mechanism
called "ni" which had a much more elaborate name resolution scheme. One
part of it was "expanding search" which would automatically look in a
package's parent package and so forth and it had a way of referring to a
module's package (by the variable __) and to package's parent (__.__).
The ni module is still there, but it's deprecated since the new builtin
package support was added in 1.5 and therefore now lives in lib-old.
Guido's essay about the builtin package support has some comments on the
reasons behind the differences between ni and the current scheme:
Intevation GmbH http://intevation.de/
More information about the Python-list