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.

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...

   -F
-- 
http://mail.python.org/mailman/listinfo/python-list

Reply via email to