Older interfaces — Python-Future documentation

# Older interfaces

In addition to the direct and `install_aliases()` interfaces (described in Standard library imports), `future` supports four other interfaces to the reorganized standard library. This is largely for historical reasons (for versions prior to 0.14).

## Context-manager for import hooks

The context-manager interface is via a context-manager called `hooks`:

    from future.standard_library import hooks
    with hooks():
        import socketserver
        import queue
        import configparser
        import test.support
        import html.parser
        from collections import UserList
        from itertools import filterfalse, zip_longest
        from http.client import HttpConnection
        import urllib.request
        # and other moved modules and definitions

This interface is straightforward and effective, using PEP 302 import hooks.

## `future.moves` interface

The `future.moves` interface avoids import hooks. It may therefore be more robust, at the cost of less idiomatic code. Use it as follows:

    from future.moves import queue
    from future.moves import socketserver
    from future.moves.http.client import HTTPConnection
    # etc.

If you wish to achieve the effect of a two-level import such as this:

    import http.client

portably on both Python 2 and Python 3, note that Python currently does not support syntax like this:

    from future.moves import http.client

One workaround is to replace the dot with an underscore:

    import future.moves.http.client as http_client

### Comparing future.moves and six.moves

`future.moves` and `six.moves` provide a similar Python 3-style interface to the native standard library module definitions.

The major difference is that the `future.moves` package is a real Python package (`future/moves/__init__.py`) with real modules provided as `.py` files, whereas `six.moves` constructs fake `_LazyModule` module objects within the Python code and injects them into the `sys.modules` cache.

The advantage of `six.moves` is that the code fits in a single module that can be copied into a project that seeks to eliminate external dependencies.

The advantage of `future.moves` is that it is likely to be more robust in the face of magic like Django’s auto-reloader and tools like `py2exe` and `cx_freeze`. See issues #51, #53, #56, and #63 in the `six` project for more detail of bugs related to the `six.moves` approach.

## `import_` and `from_import` functions

The functional interface is to use the `import_` and `from_import` functions from `future.standard_library` as follows:

    from future.standard_library import import_, from_import

    http = import_('http.client')
    urllib = import_('urllib.request')

    urlopen, urlsplit = from_import('urllib.request', 'urlopen', 'urlsplit')

This interface also works with two-level imports.

## install_hooks() call

The last interface to the reorganized standard library is via a call to `install_hooks()`:

    from future import standard_library
    standard_library.install_hooks()

    import urllib
    f = urllib.request.urlopen('http://www.python.org/')

    standard_library.remove_hooks()

If you use this interface, it is recommended to disable the import hooks again after use by calling `remove_hooks()`, in order to prevent the futurized modules from being invoked inadvertently by other modules. (Python does not automatically disable import hooks at the end of a module, but keeps them active for the life of a process unless removed.)