[issue26632] __all__ decorator

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

On Mar 25, 2016, at 02:12 AM, Eryk Sun wrote:

>I added a prototype to Python/bltinmodule.c that gets or creates the __all__
>list from the current globals (i.e. PyEval_GetGlobals).

Hi Eryk.  Can you post your diff to bltinmodule.c?  I'd like to see your code.

>It accepts at most one positional argument and any number of keyword
>arguments. It adds the positional argument's __name__ to __all__, sets it in
>globals, and returns a reference for use as a decorator. The keyword argument
>dict is used to update globals and extend __all__.

I like this.  The dual functionality of `public` looks like it will handle
almost all use cases.  I think we're in widespread agreement about the
decorator, and the keyword arguments are a nice approach to public constants.

I guess I'm a little less sure about the positional argument API.  In adding
@public to Mailman, I noticed there are a few public names which are
instances.  These could be "publicized" with the keyword argument approach,
but I don't think they can work as positional arguments, because the instances
themselves don't have __name__s.  For example, currently:

factory = DateFactory()
factory.reset()
today = factory.today
now = factory.now
layers.MockAndMonkeyLayer.register_reset(factory.reset)

__all__.extend([
    'factory',
    'now',
    'today',
    ])

With only keyword arguments, which isn't bad:

public(factory=DateFactory())
factory.reset()
public(today=factory.today, now=factor.now)

What's the use case for positionals?

>The positional argument must have a __name__ that's a string:

Right.  But what class of objects does that cover that isn't already covered
(or that explicitly appending to __all__ is good enough)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26632>
_______________________________________