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 brett.cannon
Recipients Arfrever, brett.cannon, eric.snow, ncoghlan
Date 2013-11-29.15:18:14
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1385738295.57.0.681041140136.issue19698@psf.upfronthosting.co.za>
In-reply-to
Content
This is going to have to wait until Python 3.5, so I'm going to back out the exec_module() aspects of BuiltinImporter and ExtensionFileLoader. As Nick has pointed out previously, we are going to need to change the init function signature of extension modules to accept the module to initialize (or something). This also extends to built-in modules as on Windows all extension modules are compiled in, so there is no real distinction between the two scenarios, so this can't be only partially solved for built-ins but not extension modules.

This is another reason why we will need to go with a soft deprecation of load_module() in Python 3.4 and hopefully get all of this straightened out in Python 3.5 so we can introduce a hard deprecation.

And just in case we end up having to hack our way around the call signature, PyModule_Create() could be tweaked to pull modules from a cache that can be seeded with the module that is to be used for the initialization. That way call signatures don't have to change but what module gets used can be controlled.
History
Date User Action Args
2013-11-29 15:18:15brett.cannonsetrecipients: + brett.cannon, ncoghlan, Arfrever, eric.snow
2013-11-29 15:18:15brett.cannonsetmessageid: <1385738295.57.0.681041140136.issue19698@psf.upfronthosting.co.za>
2013-11-29 15:18:15brett.cannonlinkissue19698 messages
2013-11-29 15:18:14brett.cannoncreate