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!)