[issue26632] @public - an __all__ decorator

[Nick Coghlan]

Nick Coghlan added the comment:

Chiming in so Barry & Zach can take this feedback into account for any future 
proposal:

- I think the specific term "public" has too much baggage from other languages, 
especially in the sense that it implies that "private" is the default. In 
reality, all attributes in Python are public, with __all__ serving as 
executable documentation and a constraint on wildcard exports

- the notion of an automatically supplied __all__ object that defaults to 
reporting [name for name in dir(module) if not name.startswith("_")] has a lot 
more to recommend it (as it encodes the default wildcard export behaviour 
directly into the language implementation, rather than requiring that module 
analysis tools implement that default themselves)

- given "__all__" as the base name, the method name for class and function 
registration could just be the generic "__all__.register" (although 
"__all__.export" would also work, since it's the counterpart of "import *")

- using an object namespace would allow for other registration methods if that 
seemed appropriate

Even then, I'm at best +0 on the proposal, but I also don't make heavy use of 
code development helpers (IDEs, etc)

--
nosy: +ncoghlan

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26632] @public - an __all__ decorator

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

On Jun 04, 2016, at 07:47 PM, Zachary Ware wrote:

>So, +1 anyway.  I think this would be rather worthwhile, especially in the
>stdlib.

Thanks!

I still like it and plan on continuing to use it in my code.  I would
recommend you playing with the third party module:

https://pypi.python.org/pypi/atpublic

and seeing how you like it.  If you do like it maybe help get some momentum
behind it.  Then we can approach python-dev and try to get it into builtins.
I'd be willing to bring it up there (it didn't get such an overwhelming
reception at the Pycon 2016 language summit ;).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26632] @public - an __all__ decorator

[Zachary Ware]

Zachary Ware added the comment:

I had seen this go by on new-bugs-announce, but hadn't formed an opinion about 
it.  I had also noticed several issues about __all__, but hadn't realized how 
widespread those issues were.  Now I've just been introduced to #23883 via 
#26809, and was sad to find this closed when I came to give my +1.

So, +1 anyway.  I think this would be rather worthwhile, especially in the 
stdlib.

--
nosy: +zach.ware

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26632] @public - an __all__ decorator

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

I'm going to go ahead and close this issue.  There wasn't much positive 
reception to @public in the Pycon 2016 language summit (where I presented it as 
a lightning talk).

https://gitlab.com/warsaw/public

Some of the other ideas for changes to Python may still be valid, but they 
would be best discussed under a new issue.

--
resolution:  -> wont fix
status: open -> closed
title: __all__ decorator -> @public - an __all__ decorator

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com