[Python-Dev] Breaking undocumented API

[Michael Foord]

On 09/11/2010 22:09, Nick Coghlan wrote:
> 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.

Look again. :-)

Benjamin did the refactoring into a package and he obviously dislikes 
"import *" as much as me. If he had used "import *" I would have changed 
it anyway, but he didn't.

We also define a __all__ to make the exported names explicit.

All the best,

Michael

> 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.
>


-- 

http://www.voidspace.org.uk/

READ CAREFULLY. By accepting and reading this email you agree,
on behalf of your employer, to release me from all obligations
and waivers arising from any and all NON-NEGOTIATED agreements,
licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap,
confidentiality, non-disclosure, non-compete and acceptable use
policies (”BOGUS AGREEMENTS”) that I have entered into with your
employer, its partners, licensors, agents and assigns, in
perpetuity, without prejudice to my ongoing rights and privileges.
You further represent that you have the authority to release me
from any BOGUS AGREEMENTS on behalf of your employer.