If I write a regular expression module, and then use that in my
programs, everyone who wants to use one of my programs will have to
obtain and install my regular expression module as well.
This becomes an arbitrarily large problem, because I could improve
other python modules in the same way, and because other people could
also write their own improvements.
It has been my experience that the greater the degree of idiosyncracy
in a program's environment (libraries, language extensions, etc, etc)
the more difficult it will be to install and maintain the program.
This is especially true if the environment into which the program is
being installed is also idiosyncratic.
Imagine, after a few years of code sharing with other python lovers, a
single directory of python programs and modules which contained
several distinct re-interpretations of regular expressions. Yuck.
I suppose one could write a program "packager" that would perform a
closure over "import" and then output the list of files containing the
non-standard modules required for the program.
Perhaps this points up a weakness in python. There is a good
modularization mechanism, but the concept of 'program' and 'library'
isn't yet well developed.
Could this be handled by expanding the semantics of 'import' so that
it would also scan for modules in subdirectories of directories on the
path? If it did this, multi-module programs or programs with
idiosyncratic support modules could be installed into their own
subdirectories. (The import statement would need to be changed to do
some variant of "first search the directory containing the module
executing the 'import' statement" in order to disambiguate modules
with the same name.)
This is interesting to me, because most of my python scripts are
multi-module. I even write my "shell-scripts" as modules, and I use a
special module for finding and invoking them, so that all of the
python programs in my bin look like this...
#! /usr/local/bin/python
import startscript
The startscript module is sort of neat, because it knows whether or
not the module is being run as a standalone command (and therefore
main() should be called) or whether it is being imported interactively
for debugging. (It also means that almost all of my python code is in
.pyc files.)
Tracy