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.

Title: status of module_for_loader and utils._module_to_load
Type: behavior Stage: needs patch
Components: Documentation, Library (Lib) Versions: Python 3.4
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: docs@python Nosy List: brett.cannon, docs@python, eric.snow, larry, python-dev, r.david.murray
Priority: release blocker Keywords:

Created on 2014-01-09 02:07 by r.david.murray, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (12)
msg207723 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2014-01-09 02:07
The whatsnew currently says that module_for_loader is pending deprecation in favor of utils.module_to_load, but there is no such function.  Instead there is a private function utils._module_to_load...even though there is a news entry that claimed that the non-private name was added (but there are no docs for it, nor any associated issue number).

So, importlib experts, can you clean up the docs and/or code please? :)
msg207725 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2014-01-09 03:58
utils.module_to_load() has been removed (it was introduced in 3.4) and module_for_loader() remains deprecated.  The import machinery now does the work that both functions did, rendering them unnecessary.  I guess I failed to take a look at whatsnew relative all the PEP 451 changes.
msg211127 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2014-02-13 04:14
Here is another one:

There's a news entry for the introduction of, but no news entry for its removal (but it is gone).  There is still a whatsnew entry that mentions it.

IMO there should be a NEWS entry that mentions the removal, since there is one that mentions the add.  Similarly for module_to_load.

Based on the deprecation warning in the module_for_loader code, I'm changing the whatsnew entry for its deprecation to the same text (that the import system handles it automatically) and referencing the pep 451 entry.  I get the impression from that entry that there are quite a few more importlib methods and functions that need to be listed there as deprecated.
msg211160 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2014-02-13 15:41
set_loader and set_package are also deprecated (docs are accurate for that: . Everything else that is deprecated are methods are were deprecated in Python 3.3.
msg211695 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2014-02-20 06:16
Are there still changes needed for 3.4.0?  Or is 3.4.0 okay?  This is marked as "release blocker".
msg211725 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2014-02-20 14:14
I think the docs are accurate (but I haven't been *all* the way down the NEWS chain yet).  I have a fix for whatsnew in my buffer that I haven't applied yet.  Probably this weekend.  But as a doc change, I don't see this as a release blocker anyway.
msg211943 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2014-02-22 19:29
New changeset 8f54f601fd75 by R David Murray in branch 'default':
whatsnew: importlib deprecations.
msg211944 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2014-02-22 19:35
I just committed a fix for the importlib deprecations entry, based on the deprecation notes in the docs.  There are quite a few methods deprecated in 3.4 because of modulespec, but only a few *sorts* of methods.

One possible anomaly (though it looks intentional) is that the exec_module method is deprecated, just like for the other abcs, but unlike the other abcs, there is no replacement exec_module method...instead the deprecation note directs the reader to Loader.exec_module.  I'm not familiar enough with importlib to know if that redirection would make sense to a Loader implementor.

I'm let one of the imporlib maintainers close this if they agree that I've gotten it right.
msg211974 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2014-02-23 00:10
The deprecation w/o exec_module() makes sense. The load_module() method simply called super().load_module() as the class is fully abstract and only provides get_filename() and get_data() for convenience. And since doesn't have exec_module() as abstract there's simply no need to define the method.

And thanks for doing all of this work to make the What's New doc be so thorough!
msg211978 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2014-02-23 06:56
I'll cherry-pick 8f54f601fd75.
msg211994 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2014-02-23 13:57
What you might want to do instead is wait until just before final (or until I say I am done, if we get that lucky) and copy the whole 3.4 whatsnew file over.  I'm up through Alpha 1 in the NEWS file at this point, and I do intend to continue to to work on it.
msg213794 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2014-03-17 06:30
New changeset 1640e3b7def6 by R David Murray in branch '3.4':
whatsnew: importlib deprecations.
Date User Action Args
2022-04-11 14:57:56adminsetgithub: 64398
2014-03-17 06:30:41python-devsetmessages: + msg213794
2014-02-23 13:57:17r.david.murraysetmessages: + msg211994
2014-02-23 06:56:49larrysetmessages: + msg211978
2014-02-23 00:10:35brett.cannonsetstatus: open -> closed
resolution: fixed
messages: + msg211974
2014-02-22 19:35:03r.david.murraysetmessages: + msg211944
2014-02-22 19:29:08python-devsetnosy: + python-dev
messages: + msg211943
2014-02-20 14:14:56r.david.murraysetmessages: + msg211725
2014-02-20 06:16:10larrysetmessages: + msg211695
2014-02-13 15:42:17brett.cannonsetpriority: normal -> release blocker
nosy: + larry
2014-02-13 15:41:32brett.cannonsetmessages: + msg211160
2014-02-13 04:14:45r.david.murraysetmessages: + msg211127
2014-01-09 03:58:32eric.snowsetmessages: + msg207725
2014-01-09 02:07:02r.david.murraycreate