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 leewz
Recipients barry, berker.peksag, eryksun, ethan.furman, jayvdb, leewz, martin.panter, r.david.murray, rhettinger
Date 2016-05-26.05:21:28
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1464240088.61.0.0252901998921.issue26632@psf.upfronthosting.co.za>
In-reply-to
Content
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__ to determine whether it's a method/inner function. That might have the same problems with @wraps, though, and you wouldn't be allowed to use a classmethod as a module's function.

Idea 2 seems to be the right thing. If ".__qualname__ != .__name__", it's an error. If you really want to use `public` in the above cases, you should use the assignment form of `public` (whatever it turns out to be), or explicitly append to __all__.

Rule: The programmer should not explicitly use `public(a_func)`, and should use assignment-form `public` if `@public` is not possible (== the decorator form is not being used at the point of definition). I think this way won't have errors passing silently and failing mysteriously.

First draft of error message (not considering assignment-form):
    "'public' should only be used as a decorator for a function/class in module scope."
History
Date User Action Args
2016-05-26 05:21:28leewzsetrecipients: + leewz, barry, rhettinger, r.david.murray, ethan.furman, berker.peksag, martin.panter, eryksun, jayvdb
2016-05-26 05:21:28leewzsetmessageid: <1464240088.61.0.0252901998921.issue26632@psf.upfronthosting.co.za>
2016-05-26 05:21:28leewzlinkissue26632 messages
2016-05-26 05:21:28leewzcreate