30.4. zipimport — Import modules from Zip archives — Python v2.7.2 documentation
30.4.2. Examples¶
Here is an example that imports a module from a ZIP archive - note that the
zipimport module is not explicitly used.$ unzip -l /tmp/example.zip Archive: /tmp/example.zip Length Date Time Name -------- ---- ---- ---- 8467 11-26-02 22:30 jwzthreading.py -------- ------- 8467 1 file $ ./python Python 2.3 (#1, Aug 1 2003, 19:54:32) >>> import sys >>> sys.path.insert(0, '/tmp/example.zip') # Add .zip file to front of path >>> import jwzthreading >>> jwzthreading.__file__ '/tmp/example.zip/jwzthreading.py'
30.4. zipimport — Import modules from Zip archives — Python v2.7.2 documentation
zipimport — Import modules from Zip archives¶
New in version 2.3.
This module adds the ability to import Python modules (*.py,
*.py[co]) and packages from ZIP-format archives. It is usually not
needed to use the zipimport module explicitly; it is automatically used
by the built-in import mechanism for sys.path items that are paths
to ZIP archives.Typically, sys.path is a list of directory names as strings. This module
also allows an item of sys.path to be a string naming a ZIP file archive.
The ZIP archive can contain a subdirectory structure to support package imports,
and a path within the archive can be specified to only import from a
subdirectory. For example, the path /tmp/example.zip/lib/ would only
import from the lib/ subdirectory within the archive.Any files may be present in the ZIP archive, but only files .py and
.py[co] are available for import. ZIP import of dynamic modules
(.pyd, .so) is disallowed. Note that if an archive only contains
.py files, Python will not attempt to modify the archive by adding the
corresponding .pyc or .pyo file, meaning that if a ZIP archive
doesn’t contain .pyc files, importing may be rather slow.Using the built-in reload() function will fail if called on a module
loaded from a ZIP archive; it is unlikely that reload() would be needed,
since this would imply that the ZIP has been altered during runtime.ZIP archives with an archive comment are currently not supported.
28.3. pkgutil — Package extension utility — Jython v2.5.2 documentation
28.3. pkgutil — Package extension utility¶
New in version 2.3.
This module provides functions to manipulate packages:
pkgutil.extend_path(path, name)
Extend the search path for the modules which comprise a package.
Intended use is to place the following code in a package’s
__init__.py:from pkgutil import extend_path
__path__ = extend_path(__path__, __name__)This will add to the package’s __path__ all subdirectories of
directories on sys.path named after the package. This is
useful if one wants to distribute different parts of a single
logical package as multiple directories.It also looks for *.pkg files beginning where * matches the
name argument. This feature is similar to *.pth files (see
the site module for more information), except that it doesn’t
special-case lines starting with import. A *.pkg file is
trusted at face value: apart from checking for duplicates, all
entries found in a *.pkg file are added to the path, regardless
of whether they exist on the filesystem. (This is a feature.)If the input path is not a list (as is the case for frozen
packages) it is returned unchanged. The input path is not
modified; an extended copy is returned. Items are only appended to
the copy at the end.It is assumed that sys.path is a sequence. Items of
sys.path that are not (Unicode or 8-bit) strings referring to
existing directories are ignored. Unicode items on sys.path
that cause errors when used as filenames may cause this function to
raise an exception (in line with os.path.isdir() behavior).pkgutil.get_data(package, resource)
Get a resource from a package.
This is a wrapper for the PEP 302 loader get_data() API. The
package argument should be the name of a package, in standard
module format (foo.bar). The resource argument should be in the
form of a relative filename, using / as the path separator. The
parent directory name .. is not allowed, and nor is a rooted
name (starting with a /).The function returns a binary string that is the contents of the
specified resource.For packages located in the filesystem, which have already been
imported, this is the rough equivalent of:d = os.path.dirname(sys.modules[package].__file__)
data = open(os.path.join(d, resource), ‘rb’).read()If the package cannot be located or loaded, or it uses a PEP 302
loader which does not support get_data(), then None is
returned.
28.3. pkgutil — Package extension utility — Jython v2.5.2 documentation
28.3. pkgutil — Package extension utility¶
New in version 2.3.
This module provides functions to manipulate packages:
pkgutil.extend_path(path, name)
Extend the search path for the modules which comprise a package.
Intended use is to place the following code in a package’s
__init__.py:from pkgutil import extend_path
__path__ = extend_path(__path__, __name__)This will add to the package’s __path__ all subdirectories of
directories on sys.path named after the package. This is
useful if one wants to distribute different parts of a single
logical package as multiple directories.It also looks for *.pkg files beginning where * matches the
name argument. This feature is similar to *.pth files (see
the site module for more information), except that it doesn’t
special-case lines starting with import. A *.pkg file is
trusted at face value: apart from checking for duplicates, all
entries found in a *.pkg file are added to the path, regardless
of whether they exist on the filesystem. (This is a feature.)If the input path is not a list (as is the case for frozen
packages) it is returned unchanged. The input path is not
modified; an extended copy is returned. Items are only appended to
the copy at the end.It is assumed that sys.path is a sequence. Items of
sys.path that are not (Unicode or 8-bit) strings referring to
existing directories are ignored. Unicode items on sys.path
that cause errors when used as filenames may cause this function to
raise an exception (in line with os.path.isdir() behavior).pkgutil.get_data(package, resource)
Get a resource from a package.
This is a wrapper for the PEP 302 loader get_data() API. The
package argument should be the name of a package, in standard
module format (foo.bar). The resource argument should be in the
form of a relative filename, using / as the path separator. The
parent directory name .. is not allowed, and nor is a rooted
name (starting with a /).The function returns a binary string that is the contents of the
specified resource.For packages located in the filesystem, which have already been
imported, this is the rough equivalent of:d = os.path.dirname(sys.modules[package].__file__)
data = open(os.path.join(d, resource), ‘rb’).read()If the package cannot be located or loaded, or it uses a PEP 302
loader which does not support get_data(), then None is
returned.