ASPN ActiveState Programmer Network
ActiveState
/ Home / Perl / PHP / Python / Tcl / XSLT /
/ Safari / My ASPN /
Cookbooks | Documentation | Mailing Lists | Modules | News Feeds | Products | User Groups


Recent Messages
List Archives
About the List
List Leaders
Subscription Options

View Subscriptions
Help

View by Topic
ActiveState
.NET Framework
Open Source
Perl
PHP
Python
Tcl
Web Services
XML & XSLT

View by Category
Database
General
SOAP
System Administration
Tools
User Interfaces
Web Programming
XML Programming


MyASPN >> Mail Archive >> import-sig
import-sig
Re: [Import-sig] Imports with hooks not thread safe?
by Anthony Tuininga other posts by this author
Jul 15 2002 2:47PM messages near this date
Re: [Import-sig] Imports with hooks not thread safe? | [Import-sig] SIG charters
On Sun, 2002-07-14 at 07:58, Gordon McMillan wrote:
>  On 13 Jul 2002 at 20:55, Anthony Tuininga wrote:
>  
>  > Thanks. But wouldn't it make more sense to acquire the
>  > lock around __any__ import, regardless of whether it
>  > was hooked or not? 
>  
>  You can't. Hooks typically *replace*
>  builtin.__import__. Imports from Python code
>  (where import has been hooked) don't necessarily touch
>  anything in the builtin Python import machinery.

Ok but please bear with me a moment while I struggle to understand
this....

If I look at the C code for Python (Python/import.c), any code written
in C uses PyImport_Import if it wants to invoke the import hooks that
have been set up and PyImport_ImportModuleEx if it wants to "go direct"
so to speak. Technically, the lock could be acquired and released within
PyImport_Import and this would solve __ONE__ method for importing
modules. PyImport_Import calls the __import__ method of the current
globals which is how hooks work, right?

I then found __ANOTHER__ location (Python/ceval.c) where imports are
done. This one is what is actually used for import statements found
within Python itself. It calls the __import__ method of the current
globals directly without bothering to call anything in import.c. Now
perhaps these could be reconciled, but if not, the import lock could be
acquired and released here as well. Right? Or absolutely wrong???

>  [...]
>  
>  > I agree that the exposing of the import lock would
>  > also solve the problem but that would mean that all
>  > the import hooks would have to do this in order to
>  > be thread safe. 
>  
>  Correct. Writing a good import hook isn't easy.
>  Most import hooks are specializations or extensions
>  of behavior in some little area, so can get away with
>  it.

So wouldn't it be better to make this simpler? Or would making it
simpler just cause more grief in the long run....? :-)

>  > Or could it be placed in the core
>  > imputils.py in the base class? Comments? 
>  
>  iu is a replacement for imputils. imputils has a
>  number of flaws - no import lock; it does not
>  put None in sys.modules when the "is this a
>  relative import?" test fails. Can't recall what else,
>  but that's why I wrote iu.

So wouldn't it be better to fix imputils.py to do this right? Or is it
that much of a bother to get changes to core Python?

>  
>  -- Gordon
>  http://www.mcmillan-inc.com/
>  
>  
>  
>  _______________________________________________
>  Import-sig mailing list
>  Import-sig@[...].org
>  http://mail.python.org/mailman/listinfo/import-sig
-- 
Anthony Tuininga
anthony@[...].com
 
Computronix
Distinctive Software. Real People.
Suite 200, 10216 - 124 Street NW
Edmonton, AB, Canada  T5N 4A3
Phone:	(780) 454-3700
Fax:	(780) 454-3838
http://www.computronix.com



_______________________________________________
Import-sig mailing list
Import-sig@[...].org
http://mail.python.org/mailman/listinfo/import-sig
Thread:
Anthony Tuininga
Gordon McMillan
Anthony & Janet Tuininga
Gordon McMillan
Anthony Tuininga

Privacy Policy | Email Opt-out | Feedback | Syndication
© ActiveState Software Inc. All rights reserved