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 to like it much more than I did originally. I'm using the "simple" implementation, so that means that I have a very few explicit appends to __all__. But the use of @public is actually pretty great. I don't have to worry about __all__ getting out of sync (and there turned out to be lots of places where that was happening), it's quite visually appealing (easy to pick out in a crowded file), and it avoids nasty pep8 conflicts. The major downside is actually having to import it from a module very early in the startup sequence. I stick it in mailman/__init__.py but that kind of sucks because I want to move to making that a namespace package so I want to *remove* mailman/__init__.py but there's no other obvious place to put an early `public` definition. Thus after experimenting with it, I'm much more in favor of it. Could you please describe what you don't like about it and what problems you think it will cause? (Plus, I encourage you to try it on a medium to large size project!) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26632> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
