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 belopolsky, brett.cannon, christian.heimes, grahamd, gvanrossum, ncoghlan, pitrou
Date 2010-07-14.21:29:03
SpamBayes Score 0.0005809539
Marked as misclassified No
Message-id <1279142945.08.0.232082974925.issue9260@psf.upfronthosting.co.za>
In-reply-to
Content
What I'm saying is that loaders are quite possibly not thread-safe already, so we don't need to do any special for them. If you look at PEP 302 you will notice not a single mention of loaders needing to care about the import lock because there is no mention of the import lock! So changing the locking mechanism most likely won't break loaders because they are not using the current import lock anyway and so already have their own issues.

As long as __import__ does the proper locking on behalf of loaders and we provide a way for people to use the lock if they want to then I am not worried about the impact on loaders. For example, this will change the logic in importlib where the current import lock is grabbed, but otherwise won't change a thing in terms of the code for the various loaders it implements.
History
Date User Action Args
2010-07-14 21:29:05brett.cannonsetrecipients: + brett.cannon, gvanrossum, ncoghlan, belopolsky, pitrou, christian.heimes, grahamd
2010-07-14 21:29:05brett.cannonsetmessageid: <1279142945.08.0.232082974925.issue9260@psf.upfronthosting.co.za>
2010-07-14 21:29:03brett.cannonlinkissue9260 messages
2010-07-14 21:29:03brett.cannoncreate