30.4.2. Examples

Here is an example that imports a module from a ZIP archive - note that the

module is not explicitly used.

$ unzip -l /tmp/example.zipArchive:  /tmp/example.zip  Length     Date   Time    Name --------    ----   ----    ----     8467  11-26-02 22:30   jwzthreading.py --------                   -------     8467                   1 file$ ./pythonPython 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'

— 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 module explicitly; it is automatically used

by the built-in mechanism for items that are paths

to ZIP archives.

Typically, is a list of directory names as strings. This module

also allows an item of 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 function will fail if called on a module

loaded from a ZIP archive; it is unlikely that 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

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

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.