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

[Eric Snow]

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 have any serious 
objections to making the spec the writable single-source-of-truth.

FWIW, I'd rather there were high-level helpers available as an alternative to 
the low-level practice of modifying module attrs.  However, in this case it 
probably isn't frequent enough to make it worth it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Barry A. Warsaw]

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 proxy and add the properties to ModuleType directly, 
> no?

My initial idea was to proxy from the ModuleType to the ModuleSpec and I 
started down that path, but hacking in C is much more painful than 
experimenting in Python, so that’s why I did my WIP branch (i.e. just to play 
with the feasibility of it).

Thus I had planned to keep the actual attribute values in the ModuleSpec and 
essentially implement a getattro and setattro in the ModuleType that proxied 
sets and gets to the ModuleSpec.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Barry A. Warsaw]

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 module is loaded.  PEP 
> 451 talks about the difference a little, but I'm pretty sure it came up in 
> more detail in discussions about the PEP at that time.

It’s frankly not good enough to capture the *intent* of these attributes in a 
PEP.  We need to be clear in the documentation about their purpose and we need 
to be clear about when to use or set either the module attribute or the spec 
attribute.  The current situation is ambiguous and possibly misleading.  But 
maybe it’s “just” a documentation issue?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Barry A. Warsaw]

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 (nearly) 
> duplicate attributes is confusing and I have yet to see it benefit anyone.

If we don’t implement a proxy to enforce equivalence, then we shouldn’t say as 
such in the documentation.  And we should be much clearer about what the 
purpose of the spec is versus the module attributes.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Brett Cannon]

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 to influence reloading. There's a discussion 
somewhere where I talked about this with Nick and he agreed with me that trying 
to keep specs like receipts and all of these other attributes as mutable values 
had not really panned out after all of these years.

> +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 (nearly) 
duplicate attributes is confusing and I have yet to see it benefit anyone.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Eric Snow]

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 proxy or module object).  __path__ could be 
similarly proxied but would at the least have to be mutable.

The nice thing about such attrs is they wouldn't show up in the module's 
__dict__, assuming they are properties.

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 proxy and add the properties to ModuleType directly, no?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Eric Snow]

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.  PEP 451 
talks about the difference a little, but I'm pretty sure it came up in more 
detail in discussions about the PEP at that time.

IIRC, originally PEP 451 made ModuleSpec immutable and there was a mutable 
version of it for use by finders that had a mechanism to "freeze" it.  (We 
dialed that back because it was mostly unnecessary extra complexity.)

As to the module attrs, I agree about which are unnecessary and which must stay 
(__name__, __file__, __path__).  __name__ and spec.name don't always match 
(e.g. for __main__).  Likewise for __file__ and spec.origin (e.g. frozen stdlib 
modules).

Regarding __path__, it is the only attr that has an impact on import behavior 
(other than reload) after the module is loaded, e.g. when finding submodules.  
As noted, users sometimes modify it to affect that behavior. 
 We want the spec to preserve the information used when the module was loaded, 
so __path__ and how it's used by the import machinery should stay the same.

FWIW, I've also seen cases where __loader__ is overwritten to facilitate 
different reload behavior, but don't remember if I've seen that lately (and 
don't remember offhand if that even worked after PEP 451).  Regardless, I'm not 
convinced some other solution wouldn't be better to address that use case if 
needed (e.g. add "reload_loader" to ModuleSpec with this use case in mind).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Barry A. Warsaw]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Brett Cannon]

Change by Brett Cannon :


--
title: Deprecate __loader__, __package__, __file__, and __cached__ on modules 
-> Deprecate __loader__, __package__, and __cached__ on modules

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com