Message147922
| Author |
amaury.forgeotdarc |
| Recipients |
amaury.forgeotdarc, loewis, scoder |
| Date |
2011年11月18日.20:31:11 |
| SpamBayes Score |
6.8756674e-07 |
| Marked as misclassified |
No |
| Message-id |
<1321648272.1.0.312472544137.issue13429@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
> ... and the module init function could create and register a
> different module first, and ...
Actually, this *does* happen, the PIL module is written this way.
And I don't agree with the "best effort" argument. If there is a slight chance that this does not work, we'll have to fix it sooner or later.
But please check this import lock thing: if _PyImport_AcquireLock and _PyImport_ReleaseLock are always called around extension module initialization, then we don't have to worry about other threads; and nested calls are already handled by the "oldimportcontext" variable in your patch. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2011年11月18日 20:31:12 | amaury.forgeotdarc | set | recipients:
+ amaury.forgeotdarc, loewis, scoder |
| 2011年11月18日 20:31:12 | amaury.forgeotdarc | set | messageid: <1321648272.1.0.312472544137.issue13429@psf.upfronthosting.co.za> |
| 2011年11月18日 20:31:11 | amaury.forgeotdarc | link | issue13429 messages |
| 2011年11月18日 20:31:11 | amaury.forgeotdarc | create |
|