Strange __import__() behavior

Kiuhnm kiuhnm03.4t.yahoo.it
Thu Apr 26 12:05:44 EDT 2012


On 4/26/2012 17:19, Frank Miles wrote:
> On Wed, 25 Apr 2012 23:03:36 +0200, Kiuhnm wrote:
>
>> On 4/25/2012 22:05, Frank Miles wrote:
>>> I have an exceedingly simple function that does a "named import". It
>>> works perfectly for one file "r"- and fails for the second "x".
>>>
>>> If I reverse the order of being called, it is still "x" that fails, and
>>> "r" still succeeds.
>>>
>>> os.access() always reports that the file is readable (i.e. "true")
>>>
>>> If I simply call up the python interpreter (python 2.6 - Debian stable)
>>> and manually "import x" - there is no problem - both work.  Similarly
>>> typing the __import__("x") works when typed directly at the python
>>> prompt.  Both 'x' and 'r' pass pychecker with no errors.  The same
>>> error occurs with winpdb - the exception message says that the file
>>> could not be found.  'file' reports that both files are text files, and
>>> there aren't any strange file-access permissions/attributes.
>>>
>>> Here's the function that is failing:
>>>
>>> def named_import(fname, description) :
>>>       import  os
>>>       pname= fname + '.py'
>>>       print "ENTRY FILE", pname, ": acces=", os.access(pname, os.R_OK)
>>>       try :
>>>           X=__import__(fname)
>>>           x= [ X.cmnds, X.variables ]
>>>       except ImportError :
>>>           print "failed"
>>>       return x
>>>
>>> This is the first time I've needed to import a file whose name couldn't
>>> be specified in the script, so there's a chance that I've done
>>> something wrong, but it seems very weird that it works in the CL
>>> interpreter and not in my script.
>>>
>>> TIA for any hints or pointers to the relevant overlooked documentation!
>>
>> I can't reproduce your problem on my configuration. Anyway, you should
>> note that if x.pyc and r.pyc are present, __import__ will try to import
>> them and not the files x.py and r.py. Try deleting x.pyc and r.pyc.
>>
>> Kiuhnm
>
> You are fast in replying!  I nuked my query (within a few minutes of
> posting) when I discovered the reason.  Perhaps it persisted in some
> domain.

Yes, some servers don't honor "cancel" messages.

> I'd forgotten that the python script containing the described function was
> not the file itself, but a link to the script.  When I executed the script
> (er, link to the script) - even with winpdb - apparently __import__
> examined the directory where the actual file resided.  In _that_
> directory, only 'r' existed, no 'x'.
>
> So thanks for trying, there was no way you (or anyone) could have seen
> that the script was just a link to a script...

Not true... you did ;)

Kiuhnm



More information about the Python-list mailing list