[Python-Dev] Breaking undocumented API

[Nick Coghlan]

On Wed, Nov 10, 2010 at 4:49 AM, Tres Seaver <tseaver at palladion.com> wrote:
> Outside an interactive prompt, anyone using "from foo import *" has set
> themselves and their users up to lose anyway.
>
> That syntax is the single worst misfeature in all of Python.  It impairs
> readability and discoverability for *no* benefit beyond one-time typing
> convenience.  Module writers who compound the error by expecting to be
> imported this way, thereby bogarting the global namespace for their own
> purposes, should be fish-slapped. ;)

Be prepared to fish-slap all of python-dev then - we use precisely
this technique to support optional acceleration modules. The pure
Python versions of pairs like profile/_profile and heapq/_heapq
include a try/except block at the end that does the equivalent of:

  try:
    from _accelerated import * # Allow accelerated overrides
  except ImportError:
    pass # Use pure Python versions

This allows each implementation to make its own decisions about
exactly which parts to accelerate without needing to change the pure
Python version. In CPython itself, different *builds* may vary based
on which components are available during the build process.

There are utility functions provided in test.support that allow us to
make sure that these modules are tested both with and without their
accelerated components.

The new unittest package in 2.7 and 3.2 also uses it in the module
__init__ to present the old "flat" namespace despite become a package
under the hood.

Star imports are certainly open to abuse, but there are legitimate use
cases when you want to lie about where particular APIs live in the
module heirarchy. Those use cases generally involve being imported by
one *specific* other module, such that anyone else importing the
module directly *at all* is already doing the wrong thing.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia