[Python-Dev] Breaking undocumented API (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Tue Nov 9 23:09:09 CET 2010

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

More information about the Python-Dev mailing list