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 pitrou
Recipients brett.cannon, loewis, pitrou, scoder
Date 2012-11-04.01:18:10
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1351991891.59.0.184310277559.issue16392@psf.upfronthosting.co.za>
In-reply-to
Content
> Now that you mention it - wouldn't that suffer from not actually
> knowing the FQMN? There's that hack in the dynlib loader that stores
> the package context in a global variable so that the module creation
> function can figure it out. That might be a reason not to register the 
> module automatically.

That's possible (although I would expect a module to know in which package it's supposed to live).
Another solution would have been to pass the module object to the init function, instead of letting the init function create it, but it's a bit too late (or too early :-)) to change the extension module init signature again.
History
Date User Action Args
2012-11-04 01:18:13pitrousetrecipients: + pitrou, loewis, brett.cannon, scoder
2012-11-04 01:18:11pitrousetmessageid: <1351991891.59.0.184310277559.issue16392@psf.upfronthosting.co.za>
2012-11-04 01:18:11pitroulinkissue16392 messages
2012-11-04 01:18:10pitroucreate