[issue26632] __all__ decorator

Franklin? Lee added the comment: BIKESHEDDING Here is another concern with decorators and `.__module__` (or `inspect.getmodule`). (Or is it the original concern?) If an earlier decorator creates a wrapper and doesn't set .__module__, you'll make the function public in the wrong module.

[issue26632] __all__ decorator

Franklin? Lee added the comment: I probably won't submit a patch, but I can definitely write a bunch of private notes toward a patch and forget about them. >_> Idea 1: Crawl up the call tree and see whether you hit a module definition or a class definition first. Idea 2: Inspect __qualname__

[issue26632] __all__ decorator

Barry A. Warsaw added the comment: On May 25, 2016, at 07:56 AM, Franklin? Lee wrote: >>AttributeError: 'tuple' object has no attribute 'append' >>which seems pretty obvious. > >I don't think the C version shows a traceback, so it won't be clear that >you're trying to assign to `__all__`.

[issue26632] __all__ decorator

Franklin? Lee added the comment: >>If @public were only to be used as a decorator, it would not be possible to >>have `public` called on a function outside of its definition. But someone >>might call `public(some_decorator(some_function))`. > >Do you mean, they'd call this is some module other

[issue26632] __all__ decorator

Barry A. Warsaw added the comment: On May 23, 2016, at 02:43 PM, Franklin? Lee wrote: >I sometimes wrap functions that return iterators to make functions that >return lists, because I work on the interpreter a lot. From there, it's not >much of a stretch to imagine functions which are

[issue26632] __all__ decorator

Franklin? Lee added the comment: >I don't know, but what practical effect will this have? I.e. under what >conditions would you @public wrap a @functools.wraps function and want it to >show up in __all__? Do you have a specific use case? I sometimes wrap functions that return iterators to

[issue26632] __all__ decorator

Barry A. Warsaw added the comment: On May 22, 2016, at 11:30 PM, Martin Panter wrote: >Here are two examples where publicly-documented module attributes are >intentionally omitted from __all__: > >* Issue 26234: typing.re and typing.io >* Issue 23439: HTTP status codes like

[issue26632] __all__ decorator

Martin Panter added the comment: Here are two examples where publicly-documented module attributes are intentionally omitted from __all__: * Issue 26234: typing.re and typing.io * Issue 23439: HTTP status codes like http.client.NOT_FOUND Despite these, I think @public is a reasonable name.

[issue26632] __all__ decorator

Barry A. Warsaw added the comment: On May 20, 2016, at 07:02 AM, Berker Peksag wrote: >+1 for the idea. I saw a lot of different 'all' or 'public' decorators in the >wild. It would be nice to have a complete solution in Python. It would be >good to add a note to Doc/whatsnew/3.6.rst. Is that a

[issue26632] __all__ decorator

Barry A. Warsaw added the comment: On May 20, 2016, at 07:21 AM, Franklin? Lee wrote: >I am iffy about using ``public`` to define other values. That part might be >considered unpythonic. It's a bit of a stretch. I like it for the convenience, and the implementation is simple, but if e.g.

[issue26632] __all__ decorator

Franklin? Lee added the comment: I like how ``@public`` keeps the declaration close to the definition. I am iffy about using ``public`` to define other values. That part might be considered unpythonic. Implementation issues: - ``__module__`` is not reliable. ``functools.wraps`` changes

[issue26632] __all__ decorator

Changes by Serhiy Storchaka : -- nosy: -serhiy.storchaka ___ Python tracker ___

[issue26632] __all__ decorator

Berker Peksag added the comment: +1 for the idea. I saw a lot of different 'all' or 'public' decorators in the wild. It would be nice to have a complete solution in Python. It would be good to add a note to Doc/whatsnew/3.6.rst. -- components: +Interpreter Core nosy: +berker.peksag

[issue26632] __all__ decorator

Barry A. Warsaw added the comment: Now with docs and tests. -- Added file: http://bugs.python.org/file42833/26632-in-c-5.diff ___ Python tracker ___

[issue26632] __all__ decorator

Changes by John Mark Vandenberg : -- nosy: +jayvdb ___ Python tracker ___ ___

[issue26632] __all__ decorator

Barry A. Warsaw added the comment: On May 09, 2016, at 04:19 PM, Ethan Furman wrote: >`from ... import *` should not be used with packages that do not have an >__all__ unless they support that usage (check their docs). Good idea; I added a warning-ish. --

[issue26632] __all__ decorator

Ethan Furman added the comment: For the standalone version I suggest a disclaimer about the `from ... import *` ability. Something like: `from ... import *` should not be used with packages that do not have an __all__ unless they support that usage (check their docs). --

[issue26632] __all__ decorator

Barry A. Warsaw added the comment: Here's a standalone version for older Python 3's: http://public.readthedocs.io/en/latest/ https://pypi.python.org/pypi/atpublic -- ___ Python tracker

[issue26632] __all__ decorator

Barry A. Warsaw added the comment: One more diff. As I was working on tests, I realized that the decorator version wasn't returning the thing it was decorating. Changing this also allowed me to simplify the exit path. I should be putting up a PyPI package soon which implements this for

[issue26632] __all__ decorator

R. David Murray added the comment: "This will cause more problems than it solves" and "this looks unpythonic" are, IMO, not strong arguments against it without butressing discussion. If we can have some examples of problems it will cause, or a concrete explanation of wy something that makes

[issue26632] __all__ decorator

Barry A. Warsaw added the comment: Updated. -- Added file: http://bugs.python.org/file42760/26632-in-c-3.diff ___ Python tracker ___

[issue26632] __all__ decorator

Serhiy Storchaka added the comment: Added a couple of comments on Rietveld. But sorry, the overall idea looks unpythonic to me. I'm strong -1. -- ___ Python tracker

[issue26632] __all__ decorator

Barry A. Warsaw added the comment: I think I missed a decref. New diff. -- Added file: http://bugs.python.org/file42758/26632-in-c-2.diff ___ Python tracker

[issue26632] __all__ decorator

Barry A. Warsaw added the comment: Here's a C implementation. I'm a bit under the weather so please do double check my refcounting logic. ;) No tests or docs yet, but those would be easy to add. Here's an example: @public class Foo: pass public(qux=3) print(qux) @public def zzz():

[issue26632] __all__ decorator

Barry A. Warsaw added the comment: Here's my implementation based on eryksun's idea: def public(thing=None, **kws): mdict = (sys._getframe(1).f_globals if thing is None else sys.modules[thing.__module__].__dict__) dunder_all = mdict.setdefault('__all__', [])

[issue26632] __all__ decorator

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.

[issue26632] __all__ decorator

Barry A. Warsaw added the comment: On Mar 28, 2016, at 04:26 PM, Serhiy Storchaka wrote: >There is a helper in test.support that helps to add a test for __all__, and >we slowly add these test for all modules. So this is not large issue for the >stdlib. > >New module level names are added not

[issue26632] __all__ decorator

Serhiy Storchaka added the comment: There is a helper in test.support that helps to add a test for __all__, and we slowly add these test for all modules. So this is not large issue for the stdlib. New module level names are added not very often. Keeping __all__ in sync is not the largest

[issue26632] __all__ decorator

Barry A. Warsaw added the comment: On Mar 28, 2016, at 06:34 AM, Raymond Hettinger wrote: >I have to agree with that part ;-) Sorry, but this feels "yucky" and is >likely to cause more problems than it solves. I've been experimenting with something like this in a Mailman branch and I've come

[issue26632] __all__ decorator

Serhiy Storchaka added the comment: Agree with Raymond. -- nosy: +serhiy.storchaka ___ Python tracker ___ ___

[issue26632] __all__ decorator

Raymond Hettinger added the comment: [Barry] > This is probably terrible ... I have to agree with that part ;-) Sorry, but this feels "yucky" and is likely to cause more problems than it solves. -- nosy: +rhettinger ___ Python tracker

[issue26632] __all__ decorator

Eryk Sun added the comment: > work off its __name__ and __module__ Why is __module__ required? It seems to me this should only operate on the current module. I added a prototype to Python/bltinmodule.c that gets or creates the __all__ list from the current globals (i.e. PyEval_GetGlobals).

[issue26632] __all__ decorator

Barry A. Warsaw added the comment: On Mar 25, 2016, at 12:14 AM, Ethan Furman wrote: >public = Public(globals()) > >@public >def baz(a, b): >#blah blah > >public('CONST1', 2) I'm not crazy about that, plus I rather don't like the implicit binding of the name. I suppose we should just drop

[issue26632] __all__ decorator

Ethan Furman added the comment: Not a fan. :/ How about getting your own copy of the public decorator initialized with the globals you pass in? class Public: def __init__(self, module): """ module should be the globals() dict from the calling module """

[issue26632] __all__ decorator

Barry A. Warsaw added the comment: On Mar 24, 2016, at 10:31 PM, Martin Panter wrote: >FWIW I already invented this :) as written in Issue 22247. Although I think I >only used it once or twice in my own personal librarie(s). So it’s a nice >sign that we came up with the same @public name and

[issue26632] __all__ decorator

Martin Panter added the comment: FWIW I already invented this :) as written in Issue 22247. Although I think I only used it once or twice in my own personal librarie(s). So it’s a nice sign that we came up with the same @public name and usage. I’m not a fan of hacks depending on the calling

[issue26632] __all__ decorator

Barry A. Warsaw added the comment: On Mar 24, 2016, at 02:48 AM, Ethan Furman wrote: >On the down side, you know somebody is going to @public a class' method -- >how do we check for that? Do we need to? Consenting adults and __all__. OT1H, you do get an AttributeError if you from-import-*

[issue26632] __all__ decorator

Ethan Furman added the comment: def public(thing, value=None): if isinstance(thing, str): mdict = sys._getframe(1).f_globals name = thing mdict[name] = thing # no need for retyping! ;) else: mdict = sys.modules[thing.__module__].__dict__ name =

[issue26632] __all__ decorator

Changes by Ethan Furman : -- nosy: +ethan.furman ___ Python tracker ___ ___

[issue26632] __all__ decorator

Barry A. Warsaw added the comment: Oh, and it should be a built-in -- ___ Python tracker ___ ___

[issue26632] __all__ decorator

New submission from Barry A. Warsaw: This is probably terrible, but given how difficult it is to keep __all__'s up to date, maybe something like this can be useful. I literally whipped this up in about 5 minutes, so sit back and watch the bikeshedding! import sys def public(thing): if