It's been a while since I have used Python and am stumbling already at a simple import!
statements.py:
str = "hello"
main.py:
import statements
print statements.str
Obviously the final program will have more going on, and the statements will be stuff like URLs. For this simple example however with both files sitting side by side in the same folder I get the following error on running main.py:
AttributeError: 'module' object has no attribute 'str'
I know I am doing something terribly silly, but I can't see what it is. Searching around it looks fine. Any help/insight is appreciated.
You used the import statement correctly. The error then can be caused by either importing a different module with the same name, or by having altered the module after already having imported it.
You can check print statements.__file__ to see what module Python found instead when importing, and you can use the reload() function to ask Python to reload the module from disk if you altered it.
Related
This question already has answers here:
Python program importing itself
(4 answers)
Closed 3 months ago.
In a simple Program in BugTest.py:
from BugTest import *
print("Hello World")
note my error in importing BugTest.py from BugTest.py
Here is the output:
Hello World
Hello World
My question is: Why doesn't this cause a compile error? Is this a bug in Python?
Why does it only import twice, rather than enter an infinite loop?
Why doesn't this cause a compile error?
Because it's completely valid syntax. The only error (absent a problem in the Python runtime itself, such as running out of memory or failing to find the source code) that can occur at compile time in Python is SyntaxError. Names are only resolved at runtime.
That said, it's also completely valid at runtime.
Why does it only import twice, rather than enter an infinite loop?
from BugTest import * means - roughly - "look for an existing module named BugTest; if not found, find and load BugTest.py, create a module object from it named BugTest, and put it in the module cache. Then, copy all the names from the BugTest module into the current module (overwriting any existing names)."
When you run the program, Python creates a module object from the BugTest.py code, and (very usefully) gives it the special name __main__. Then it runs the top-level code, triggering the import statement. Now it creates another module object from the BugTest.py code, giving it the usual name of BugTest. That module's top-level code runs as well; but when it tries to import, a BugTest module is already in the module cache.
You executed
$ python BugTest.py
which asked for two statements to run,
an import and a print.
The pair of statements ran exactly once.
The first statement performed an import,
which has the side effect of printing a line.
Then the second statement, a print,
printed a line as requested.
Everything happened according to plan.
It is usually considered undesirable for
an import to have side effects
such as print().
In this case, of course,
it makes perfectly good sense
during debugging.
Once imported,
a module appears in a hash table
and will not be re-imported again.
So attempting a double import
here would not provoke three lines of output.
That is, having done (a possibly time
consuming) import x,
we won't see x imported again.
If top-level, or any transitive
dependencies imported by top-level,
asks for import x, it is simply
skipped, as a cache hit.
I see in several old questions that around the switch from Python 2 to Python 3, implicit relative imports were not allowed. However, I ran into a problem that seems to suggest they do happen and am wondering if something changed or if my understanding is incorrect. Edit: To clarify, I thought the below would not be an implicit relative import, but it seems to act like it.
I made an empty file called queue.py and another file called uses_queue.py which contains:
from multiprocessing import Queue
q = Queue()
which crashes on execution saying ImportError: cannot import name 'Empty' from 'queue' however it will not crash if I delete that aforementioned empty file called queue.py. Changing from multiprocessinging to from .multiprocessing or _multiprocessing or ._multiprocessing which didn't change anything.
I've got a Python script.
I've had several functions in this script which I decided to move to a 'package' folder beside the main script.
In this folder, I created a *.py file where I put all my functions.
I've placed an empty init.py near this file within the 'package' folder.
When starting the code of my main script with:
from package_folder.my_functions import *
the script works well when calling every functions from that file.
But when trying to import it directly:
import package_folder.my_functions
it doesn't seems to work as well as with the above technique.
The cause seems to be the fact that in the file wellmy_functions.py, I have a function that needs an other one, declared previously in that file.
I had this obscure error on that function that needs an other one:
TypeError: 'NoneType' object is not callable
Is this permissible and if not, how to manage this case?
It's generally not a good idea to use from module import *. Wildcard importing leads to namespace pollution; you imported more names than you need and if you accidentally refer to an imported name you may not get the NameError you wanted.
Also, if a future version of the library added additional names, you could end up masking other names, leading to strange bugs still:
Example
from my_mod1 import func1
from my_mod2 import *
If you upgrade my_mod2 and it now includes a my_mod2.func1 it'll replace the my_mod1.func1 import in the 1st line.
Note: Solved. It turned out that I was importing a previous version of the same module.
It is easy to find similar topics on StackOverflow, where someone ran into a NameError. But most of the questions deal with specific modules and the solution is often to update the module.
In my case, I am trying to import a function from a module that I wrote myself. The module is named InfraPy, and it is definitely on sys.path. One particular function (called listToText) in InfraPy returns a NameError, but only when I try to import it into another script. Inside InfraPy, under if __name__=='__main__':, the listToText function works just fine. From InfraPy I can import other functions with no problems. Including from InfraPy import * in my script does not return any errors until I try to use the listToText function.
How can this occur?
How can importing one particular function return a NameError, while importing all the other functions in the same module works fine?
Using python 2.6 on MacOSX 10.6, also encountered the same error running the script on Windows 7, using IronPython 2.6 for .NET 4.0
Thanks.
If there are other details you think would be helpful in solving this, I'd be happy to provide them.
As requested, here is the function definition inside of InfraPy:
def listToText(inputList, folder=None, outputName='list.txt'):
'''
Creates a text file from a list (with each list item on a separate line). May be placed in any given folder, but will otherwise be created in the working directory of the python interpreter.
'''
fname = outputName
if folder != None:
fname = folder+'/'+fname
f = open(fname, 'w')
for file in inputList:
f.write(file+'\n')
f.close()
This function is defined above and outside of if __name__=='__main__':
I've tried moving InfraPy around in relation to the script. The most baffling situation is that when InfraPy is in the same folder as the script, and I import using from InfraPy import listToText, I receive this error: NameError: name listToText is not defined. Again, the other functions import fine, they are all defined outside of if __name__=='__main__': in InfraPy.
This could happen if the module has __all__ defined
Alternatively there could be another version of the module in your path that is getting imported instead of the one you are expecting
Is the NameError about listToText or is it something inside the function causing the exception?
In addition the __all__ variable gnibbler mentioned you could also have a problem with a InfraPy.pyc file lying around somewhere.
I'd recommend putting a import pdb;pdb.set_trace() first in the InfraPy.py file to make sure you are in the right file, and step through the definition of InfraPy.py to see what is happening. If you don't get a breakpoint, you are importing another file than you think.
You can also dir(InfraPy) after importing it, and check which file you are actually importing with InfraPy.__file__.
Can't think of any more import debugging hints right now. ;-)
This question already has answers here:
Importing installed package from script with the same name raises "AttributeError: module has no attribute" or an ImportError or NameError
(2 answers)
Closed 6 years ago.
If I start python from the command line and type:
import random
print "Random: " + str(random.random())
It prints me a random number (Expected, excellent).
If I include the above-two lines in my django application's models.py and start my django app with runserver I get the output on the command line showing me a random number (Great!)
If I take a custom tag which works perfectly fine otherwise, but I include
import random
print "Random: " + str(random.random())
as the first 2 lines of the custom tag's .py file, I get an error whenever I try to open up a template which uses that custom tag:
TypeError at /help/
'module' object is not callable
Please keep in mind that if I get rid of these two lines, my custom tag behaves as otherwise expected and no error is thrown. Unfortunately, I need some random behavior inside of my template tag.
The problem is if in a custom tag I do:
import random
on a custom template tag, it imports
<module 'django.templatetags.random' from '[snip path]'>
and not
<module 'random' from 'C:\\Program Files\\Python26\\lib\\random.pyc'>
as is normally imported from everywhere else
Django template library has a filter called random, and somehow it is getting priority above the system's random.
Can anyone recommend how to explicitly import the proper python random?
The answer is ... strange.
When I originally wrote my custom tag, I called it random.py. I quickly realized that this name may not be good and renamed it randomchoice.py and deleted my random.py file. Python kept the compiled random.pyc file around, and it was getting loaded whenever I did import random. I removed my random.pyc file, and the problem went away.
Yes, this kind of error is pretty easy. Basically don't name any of your filenames or anything you create with the same names as any likely python modules you are going to use.
Its been a while since I tinkered around with Django, but if random.random is a "module", then try random.random.random(). Or maybe just try random(). You just don't know what kind of hackery goes on behind the scenes.
Edit
Try this:
sys.path = [r"C:\Program Files\Python26\lib\"] + sys.path
import random
sys.path.pop(0)