Message 266746 - Python tracker (original) (raw)

BIKESHEDDING

Here is another concern with decorators and .__module__ (or inspect.getmodule). (Or is it the original concern?)

If an earlier decorator creates a wrapper and doesn't set .module, you'll make the function public in the wrong module.

@public
@bad_wrapper
def f(...): ...

IMO, the correct solution is a new stdlib function, to get the currently-loading module. You wouldn't need explicit frame hacking, and it will be portable between different Python implementations because each implementation will have to define it correctly.

The problem with this solution is the lack of other usecases for such a function, though maybe someone in python-ideas can think of one.

Candidate owners: sys, importlib.

Candidate names:

Effect:

Other solutions include:


I think nonexistence of module.all should be an error.

The behavior with a module with all is very different from one without, so I think that if you want your module to have all, you should be required to create it, even if it's empty.

Assuming that all is, by convention, always near the top, someone reading your code would know whether the first dozen or so functions are part of the public interface, without searching for @public.