[Ted Berg]
>Background:
>I'm distributing a java application in executable jar format. My goal is to
>offer python as a scripting engine for the application, and to that end I
>wish to distribute the jython Lib/ modules as part of the jar, such that user
>scripts can import these modules.
>
>1. Modules in the root directory of the jar may be imported normally
Right.
>2. Modules in a subdirectory of the jar may be imported iff a __init__.py
>module also appears in that subdirectory.
If there is a __init__.py file it is actually a package.
>3. Attempts to import modules from a subdirectory without a corresponding
>__init__.py file yield a "ImportError: no module named X" exception, where X
>is the subdirectory.
Correct. This matches the normal behaviour for file-system directories.
>I assume this is because /path/to/jarfile is a valid addition to the sys.path
Correct (assuming that "jarfile" ends with .jar or .zip).
>and /path/to/jarfile!/subdirectory is not a valid addition and is ignored.
Wrong. The jar file name must still and with .zip or .jar and normally
the subdirectory in the .jar file is not an absolute path. Try to add
/path/to/jarfile.jar!subdirectory
instead.
>Am I correct in also assuming that the __init__.py file causes the python
>interpreter to treat the *directory* as a module itself?
Yes, that is a valid way of looking at a package.
>If this is the
>case, why does an __init__.py placed in the jar root directory not get
>executed, allowing me to import subdirectories without the need for
>__init__.py files in them?
It wouldn't make sense. If there is more than one .jar file on sys.path,
when should the __init__.py files be executed and in what namespace?
>Honestly, this isn't a really big deal. It makes for some strange looking
>import clauses if you're used to CPython ( from Lib import string ),
Yuck! This is certainly the wrong approach. I believe it is already
possible to avoid this hackery entirely.
regards,
finn
|
