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-31.09:38:59
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1464687540.12.0.883124945696.issue26632@psf.upfronthosting.co.za>
In-reply-to
Content
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:
- sys.getloadingmodule()
- importlib.currentimport()
- importlib.???()

Effect:
- Returns the "innermost" loading module. If no module is loading, returns None?
- In a thread, return the module being loaded in that thread (possibly None, even if other threads are loading modules).
- (I don't know what I'm talking about:) If a Python implementation uses multithreaded loading, each thread whose result could immediately be loaded into the module's namespace (i.e. it's close to the "surface" of the load) is considered to be loading that module.
- Needs to handle re-imports, such as from `importlib.reload`.

Other solutions include:
- Require explicit `@public(__all__)` (or `__module__`)
- Special `super()`-like treatment of `public` which automatically inserts the `__all__` (or whatever).
- Hope that bad wrappers don't come up.


----

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`.
History
Date User Action Args
2016-05-31 09:39:00leewzsetrecipients: + leewz, barry, rhettinger, r.david.murray, ethan.furman, berker.peksag, martin.panter, eryksun, jayvdb
2016-05-31 09:39:00leewzsetmessageid: <1464687540.12.0.883124945696.issue26632@psf.upfronthosting.co.za>
2016-05-31 09:39:00leewzlinkissue26632 messages
2016-05-31 09:38:59leewzcreate