[issue33277] Deprecate __loader__, __package__, and __cached__ on modules

Eric Snow added the comment: I ended up writing up more thoughts on this in the issue about __package__: https://bugs.python.org/issue45540#msg404619. Users can call importlib.util.find_spec(), which is probably good enough to figure out how a module was originally imported. So I don't

[issue33277] Deprecate __loader__, __package__, and __cached__ on modules

Barry A. Warsaw added the comment: On Oct 20, 2021, at 08:28, Eric Snow wrote: > > The only catch I see is where the module's code sets one of the attrs. Would > the proxy (or import machinery) pick those up, or maybe for some of them emit > a warning or fail? > > We could also skip the

[issue33277] Deprecate __loader__, __package__, and __cached__ on modules

Barry A. Warsaw added the comment: On Oct 20, 2021, at 08:18, Eric Snow wrote: > The spec identifies how a module should be loaded (or how it was loaded and > should be reloaded). We should be careful to preserve that identify and not > invite uses to modify the spec after (or while) the

[issue33277] Deprecate __loader__, __package__, and __cached__ on modules

Barry A. Warsaw added the comment: On Oct 20, 2021, at 11:31, Brett Cannon wrote: > >> +1 on a proxy (with read-only attrs) for everything but __name__, __file__, >> and __path__ (which can all be different than the spec). > > I'm -1 on a proxy as that doesn't simplify the situation. Having

[issue33277] Deprecate __loader__, __package__, and __cached__ on modules

Brett Cannon added the comment: > The spec identifies how a module should be loaded (or how it was loaded and > should be reloaded). We should be careful to preserve that identify and not > invite uses to modify the spec after (or while) the module is loaded. But they may want to modify it

[issue33277] Deprecate __loader__, __package__, and __cached__ on modules

Eric Snow added the comment: +1 on a proxy (with read-only attrs) for everything but __name__, __file__, and __path__ (which can all be different than the spec). Ideally __name__ and __file__ would be read-only too but they'd have to be stored somewhere other than the spec (e.g. on the

[issue33277] Deprecate __loader__, __package__, and __cached__ on modules

Eric Snow added the comment: (Not sure how I missed this issue.) The spec identifies how a module should be loaded (or how it was loaded and should be reloaded). We should be careful to preserve that identify and not invite uses to modify the spec after (or while) the module is loaded.

[issue33277] Deprecate __loader__, __package__, and __cached__ on modules

Change by Barry A. Warsaw : -- keywords: +patch pull_requests: +27347 stage: test needed -> patch review pull_request: https://github.com/python/cpython/pull/29078 ___ Python tracker

[issue33277] Deprecate __loader__, __package__, and __cached__ on modules

Change by Brett Cannon : -- title: Deprecate __loader__, __package__, __file__, and __cached__ on modules -> Deprecate __loader__, __package__, and __cached__ on modules ___ Python tracker