New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
import subprocess hangs for ~25 seconds, time.py file in dir - py 2.7.3, & 2.6.6 #61326
Comments
import subprocess hangs for ~25 seconds, 700+ files in dir - py 2.7.3, & 2.6.6 I'm running this test from a LiveCD to make sure the environment is relatively clean. ------------------ import subprocess print "Done......." ------------------- ------------------- real 0m0.027s --- BUT--- <<< This cannot be right>>> import subprocess print "Done......." real 0m25.336s Only change is the number of files in the directory. FWIW, I do not see the problem when using python3.. localhost jonesda0 # yum -y install python3 Dependency Installed: Complete! real 0m0.048s real 0m0.091s localhost jonesda0 # python3 --version |
That line (100000000) seems to pop up every time the subprocess call "hangs" |
Distros tested with include Funduntu 2012-4, Fuduntu 2013-1, Fedora 17, Scientific Linux 6.3 & OpenSUSE 12.2 (all 32-bit) on the same hardware. |
I think I found something but I do not know what it means. [jonesda0@linux-2py2 pycode]$ ls -1tr |
Could you give us the contents of your time.py file? I wonder if there's something in that file that is causing the import to hang. It's the only reason I can think of as to why the time.pyc file shows up. Also, if you want to check before-hand, make a new directory with just those two files and see what happens. |
As a further note, on python 2.6, I just touched a file called time.py, and in the interpreter imported subprocess. It didn't hang because the file was empty but it did generate a pyc file. This is almost certainly the root of your problem. I doubt this is a core python problem. |
Hello Ian. As I imagine you understand, I delete the "time.pyc" file every time it comes back. That being said, there *is* a "time.py" script in there from some testing I was doing: [jonesda0@toshiba pycode]$ ls -1tr *.py* | egrep "sp|time" while (i < 100000000):
# i = i + 1
i+=1
# j = j + 1
j+=1 print j -------------------------- [jonesda0@toshiba pycode]$ python sp.py ------------------------------ import subprocess print ("Done.......") So where does this behavior come from? [jonesda0@toshiba pycode]$ cat time.pyc ## There is all sorts of Escape code in the file, obviously. --------------------------------- [jonesda0@toshiba pycode]$ rm -f time.pyc real 0m0.027s [jonesda0@toshiba pycode]$ ls -1tr *.py* | egrep "sp|time" -------------------------- Thanks |
Tried to edit subject to make it easier to search |
You happen to have a script named time.py, so when the subprocess module is imported, it imports this script instead of the correct time module. |
Dave, at some point during the import of subprocess the time module is apparently imported. Because of how imports work, it is importing your local copy instead of the standard library version. I would wager money that if you ran time python time.py (on your script) it would take roughly 25 seconds. If I run python verbosely and then import subprocess, I get the following output >>> import subprocess
# /usr/lib64/python2.6/subprocess.pyc matches /usr/lib64/python2.6/subprocess.py
import subprocess # precompiled from /usr/lib64/python2.6/subprocess.pyc
# /usr/lib64/python2.6/traceback.pyc matches /usr/lib64/python2.6/traceback.py
import traceback # precompiled from /usr/lib64/python2.6/traceback.pyc
import gc # builtin
dlopen("/usr/lib64/python2.6/lib-dynload/time.so", 2);
import time # dynamically loaded from /usr/lib64/python2.6/lib-dynload/time.so
That is without the time.py file in the directory. When the file does exist there, I get the following:
>>> import subprocess
# /usr/lib64/python2.6/subprocess.pyc matches /usr/lib64/python2.6/subprocess.py
import subprocess # precompiled from /usr/lib64/python2.6/subprocess.pyc
# /usr/lib64/python2.6/traceback.pyc matches /usr/lib64/python2.6/traceback.py
import traceback # precompiled from /usr/lib64/python2.6/traceback.pyc
import gc # builtin
import time # from time.py
# wrote time.pyc In short, python checks your current working directory for a file to import. If it finds it, it uses that first. You can examine the order in which python looks for modules and packages by importing sys and looking at sys.path. This issue can be closed. If you have further questions Dave, feel free to email me personally and I'll do my best to answer them. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: