[Python-Dev] Import lock considered mysterious

Cameron Simpson cs at zip.com.au
Fri Jul 22 11:58:46 CEST 2011


On 22Jul2011 21:29, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
[...]
| This whole episode seems to have resulted from a collision
| between two rather obscure things: that import statements
| involve locking things,

Necessary to avoid performing the module definitons twice when a module
is imported twice, surely?

| and that some fairly innocuous
| looking calls, such as s.encode('ascii'), can trigger an
| import.

There are plenty of occasions where an import might be deferred until a
function call - it is a common workaround for otherwise circular
imports. Personally I also sometimes defer an import if I'm importing
something "large" that the module would only depend upon on in unusual
(or anyway, often avoidable) circumstances; for example, a facility not
in the stdlib, which a caller might avoid requiring by choosing a
different aspect of the importing module such as choosing a CSV storage
backend over and SQLalchemy backend.

| Is it really necessary to hold the import lock for so long?
| Presumably the import lock is there to protect access to
| things like sys.modules. Is that all? Could it be released
| after the module code is loaded and sys.modules has been
| updated, but before executing the module body?

Sometimes names are made by executing the module body.
Since one expects to access the module's names after the import, how is
this avoidable?

Cheers,
-- 
Cameron Simpson <cs at zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

What's the point of having Nebraska if we can't put it to its highest and
best use?       - Patrick Bedard arguing for a 100 mph speed limit


More information about the Python-Dev mailing list