This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author barry
Recipients barry, eryksun, ethan.furman, martin.panter, rhettinger, serhiy.storchaka
Date 2016-03-28.12:14:03
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <20160328081358.318f27dd@anarchist>
In-reply-to <1459146874.7.0.586979056214.issue26632@psf.upfronthosting.co.za>
Content
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!)
History
Date User Action Args
2016-03-28 12:14:04barrysetrecipients: + barry, rhettinger, ethan.furman, martin.panter, serhiy.storchaka, eryksun
2016-03-28 12:14:04barrylinkissue26632 messages
2016-03-28 12:14:03barrycreate