pyobjc-dev

[Pyobjc-dev] The meaning of __all__

[Jack J. <Jac...@cw...>]

There's a discussion over on the pyobjc developers mailing list at the 
moment about the use of __all__.

Some people suggested that for a certain module we only put "often 
used" items in __all__, so that "from module import *" will import only 
these commonly used items into your namespace. The module would contain 
other items which *are* useful and which should be callable from the 
outside, but these would have to be explicitly imported into your 
namespace (or used via "import objc; objc.SetVerbose()".

This doesn't feel right to me, as I've always used __all__ to mean "the 
whole externally visible API", and I've considered anything else that 
the module exports basically an artefact of the implementation. But 
when I looked this up in the reference manual it is rather vague about 
this.

Any opinions on the matter?
--
Jack Jansen, <Jac...@cw...>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

[Pyobjc-dev] Re: [Python-Dev] The meaning of __all__

[<ba...@py...>]

>>>>> "JJ" == Jack Jansen <Jac...@cw...> writes:

    JJ> Some people suggested that for a certain module we only put
    JJ> "often used" items in __all__, so that "from module import *"
    JJ> will import only these commonly used items into your
    JJ> namespace.

I hope __all__ isn't just for from-import-* support.  If so, maybe we
should get rid of most of them in the ongoing quest to actively
discourage from-import-* (or better yet, set them to the empty list).

-Barry

[Pyobjc-dev] Re: [Python-Dev] The meaning of __all__

[Skip M. <sk...@po...>]

    Jack> This doesn't feel right to me, as I've always used __all__ to mean
    Jack> "the whole externally visible API", and I've considered anything
    Jack> else that the module exports basically an artefact of the
    Jack> implementation. But when I looked this up in the reference manual
    Jack> it is rather vague about this.

I believe you are correct.  If it's in the external API and is (or should
be) documented, it belongs in __all__.

Skip

[Pyobjc-dev] Re: [Python-Dev] The meaning of __all__

[Guido v. R. <gu...@py...>]

> There's a discussion over on the pyobjc developers mailing list at the 
> moment about the use of __all__.
> 
> Some people suggested that for a certain module we only put "often 
> used" items in __all__, so that "from module import *" will import only 
> these commonly used items into your namespace. The module would contain 
> other items which *are* useful and which should be callable from the 
> outside, but these would have to be explicitly imported into your 
> namespace (or used via "import objc; objc.SetVerbose()".
> 
> This doesn't feel right to me, as I've always used __all__ to mean "the 
> whole externally visible API", and I've considered anything else that 
> the module exports basically an artefact of the implementation. But 
> when I looked this up in the reference manual it is rather vague about 
> this.
> 
> Any opinions on the matter?

__all__ should contain the entire public API.  It's mostly intended to
avoid accidentally exporting other things you've *imported* like os,
sys, and other library modules.  Another way of doing that would be
to write e.g.

  import sys as _sys

but I don't like excessive underscoring.

--Guido van Rossum (home page: http://www.python.org/~guido/)