If I import os module, I can run the following to infer the location of os.py
>>> import os
>>> print os.__file__
/usr/lib/python2.6/os.pyc
However, when I import posix, it does not have the __file__ attribute. Is it because it is implemented as a part of the python runtime, not as a standard library?
How can I find out more information like this using solely the python official documentation?
It's a C module. It can be either built into the Python binary or compiled as a shared library. In your case it is compiled in
The official docs say not to import it directly, and you should use the functionality provided via os
Run python interactively.
>>> import posix
>>> help(posix)
There's a lot of good stuff there.
FILE
(built-in)
You can also use the 'inspect' module to find information (say source file path etc) about a python module. For example:
import inspect
import os
inspect.getsourcefile(os)
'/usr/local/lib/python2.7/os.py'
inspect.getsourcefile(inspect)
'/usr/local/lib/python2.7/inspect.py'
import sys
inspect.getsourcefile(sys)
Traceback (most recent call last):
[...]
raise TypeError('{!r} is a built-in module'.format(object))
TypeError: <module 'sys' (built-in)> is a built-in module
Related
Python newbie question...
I am using Python3.6 on macOS and I have installed argpase using
sudo pip3 install argparse
pip3 list does not list argparse but I can see it is installed because "help("argparse") in python3 displays the documentation.
But when I write the following simple test program I receive the error: " 'argparse' has no 'ArgumentParser' member"
import argparse
parser = argparse.ArgumentParser()
parser.parse_args()
Ideas?
Thanks in advance
Based on the comments, we know that the issue was that the user created a file called argparse.py, which shadowed the standard library argparse. An easy way to detect if this is the case is to print out the file path location of a module.
>>> import argparse
>>> print(argparse.__file__)
>>> # alternatively you can use inspect
>>> import inspect
>>> print(inspect.getsourcefile(argparse))
This will show where the file is located. It would be easy to debug the problem when you see the file path that is being used.
I'm trying to reload a module I have already imported in Python 3. I know that you only need to import once and executing the import command again won't do anything.
Executing reload(foo) is giving this error:
Traceback (most recent call last):
File "(stdin)", line 1, in (module)
...
NameError: name 'reload' is not defined
What does the error mean?
reload is a builtin in Python 2, but not in Python 3, so the error you're seeing is expected.
If you truly must reload a module in Python 3, you should use either:
importlib.reload for Python 3.4 and above
imp.reload for Python 3.0 to 3.3 (deprecated since Python 3.4 in favour of importlib)
For >= Python3.4:
import importlib
importlib.reload(module)
For <= Python3.3:
import imp
imp.reload(module)
For Python2.x:
Use the in-built reload() function.
reload(module)
import imp
imp.reload(script4)
To expand on the previously written answers, if you want a single solution which will work across Python versions 2 and 3, you can use the following:
try:
reload # Python 2.7
except NameError:
try:
from importlib import reload # Python 3.4+
except ImportError:
from imp import reload # Python 3.0 - 3.3
I recommend using the following snippet as it works in all python versions (requires six):
from six.moves import reload_module
reload_module(module)
For python2 and python3 compatibility, you can use:
# Python 2 and 3
from imp import reload
reload(mymodule)
If you don't want to use external libs, then one solution is to recreate the reload method from python 2 for python 3 as below. Use this in the top of the module (assumes python 3.4+).
import sys
if(sys.version_info.major>=3):
def reload(MODULE):
import importlib
importlib.reload(MODULE)
BTW reload is very much required if you use python files as config files and want to avoid restarts of the application.....
Im trying to compile Godot engine following the instructions here
When I run scons bin/godot as the tutorial says, I get the following error:
scons: Reading SConscript files ...
ImportError: cannot import name _args_from_interpreter_flags:
File "/home/grayfox/github/godot2/godot/SConstruct", line 9:
import multiprocessing
File "/usr/lib64/python2.7/multiprocessing/__init__.py", line 65:
from multiprocessing.util import SUBDEBUG, SUBWARNING
File "/usr/lib64/python2.7/multiprocessing/util.py", line 40:
from subprocess import _args_from_interpreter_flags
The SConstruct file starts this way:
EnsureSConsVersion(0,14);
import string
import os
import os.path
import glob
import sys
import methods
import multiprocessing
...
If I try to run python SConstruct I get an error complaining about missing functions defined by scons (i.e. the script fails after doing all the imports).
Commenting import multiprocessing fixes the issue but I don't want to modify that file, as I would have to revert the change if I ever make a pull request. The project is quite active so I believe this has something to do with my local configuration.
Any ideas why the script is failing to import _args_from_interpreter_flags only if I execute it via scons?
[UPDATE]
I did a fresh Gentoo install and the problem persists. I did some tests and I found this:
In a python terminal>
>>> import SCons.Script
>>> from subprocess import _args_from_interpreter_flags
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: cannot import name _args_from_interpreter_flags
>>> import subprocess
>>> subprocess.__file__
'/usr/lib64/python2.7/site-packages/SCons/compat/_scons_subprocess.pyc'
But the output is different if I do this:
>>> import subprocess
>>> subprocess.__file__
'/usr/lib64/python2.7/subprocess.pyc'
So I update my question: Is this a bug? Can anybody reproduce it in other distros? If it's a bug, should I report it to Gentoo or to SCons?
[ANOTHER UPDATE]
Adding temp.extend([os.path.join(x, 'lib64') for x in prefs]) did't work, same error.
Adding print sys.path at the beginning of the compact module gives:
['/usr/lib64/python-exec/python2.7/scons-local-2.3.0',
'/usr/lib64/python-exec/python2.7/scons-local',
'/usr/lib64/python2.7/site-packages/lib32/scons-2.3.0',
'/usr/lib32/scons-2.3.0',
'/usr/local/lib32/scons-2.3.0',
'/usr/lib64/python2.7/site-packages/lib/python2.7/site-packages/scons-2.3.0',
'/usr/lib/python2.7/site-packages/scons-2.3.0',
'/usr/local/lib/python2.7/site-packages/scons-2.3.0',
'/usr/lib64/scons-2.3.0',
'/usr/lib64/python2.7/site-packages/lib32/scons',
'/usr/lib32/scons',
'/usr/local/lib32/scons',
'/usr/lib64/python2.7/site-packages/lib/python2.7/site-packages/scons',
'/usr/lib/python2.7/site-packages/scons',
'/usr/local/lib/python2.7/site-packages/scons',
'/usr/lib64/scons',
'/usr/lib64/python2.7/site-packages/RBTools-0.6-py2.7.egg',
'/usr/lib64/python27.zip',
'/usr/lib64/python2.7', #It's here, so what's the problem?
'/usr/lib64/python2.7/plat-linux2',
'/usr/lib64/python2.7/lib-tk',
'/usr/lib64/python2.7/lib-old',
'/usr/lib64/python2.7/lib-dynload',
'/usr/lib64/python2.7/site-packages',
'/usr/lib64/python2.7/site-packages/gtk-2.0',
'/usr/lib64/python2.7/site-packages/wx-2.8-gtk2-unicode']
It looks as if this isn't really a problem connected to SCons directly. You might have an alien "subprocess" module/package installed in your system. Also check out Cannot import name _args_from_interpreter_flags which seems to be related.
Based on your updated question: I tried to compile Godot on my machine (Python 2.7.3, SCons 2.3.1, Ubuntu 12.04 LTS) and it's running fine, so the problem is not related to the provided SConstruct (and its supporting build description files in subfolders). The "_scons_subprocess" module gets used only when the import of the original "subprocess.py" fails. So I suspect that the SCons start script sets up a wrong sys.path, which may happen under 64bit (see issue http://scons.tigris.org/issues/show_bug.cgi?id=2657 ).
After you added "temp.extend([os.path.join(x, 'lib64') for x in prefs])", your "print sys.path" statement shows paths like "/usr/lib64/python-exec" in its output. A Google search turned up the page http://forums.gentoo.org/viewtopic-t-985402-start-0.html for me. It describes an issue with Gentoo, where programs are installed as links to pip. Please follow the given advice and see if this fixes your problem.
It's a bug in Gentoo's scons-2.3.0 and scons-2.3.1 ebuilds (see bug report). It has been fixed in versions 2.3.1-r1 and higher.
I'm trying to reload a module I have already imported in Python 3. I know that you only need to import once and executing the import command again won't do anything.
Executing reload(foo) is giving this error:
Traceback (most recent call last):
File "(stdin)", line 1, in (module)
...
NameError: name 'reload' is not defined
What does the error mean?
reload is a builtin in Python 2, but not in Python 3, so the error you're seeing is expected.
If you truly must reload a module in Python 3, you should use either:
importlib.reload for Python 3.4 and above
imp.reload for Python 3.0 to 3.3 (deprecated since Python 3.4 in favour of importlib)
For >= Python3.4:
import importlib
importlib.reload(module)
For <= Python3.3:
import imp
imp.reload(module)
For Python2.x:
Use the in-built reload() function.
reload(module)
import imp
imp.reload(script4)
To expand on the previously written answers, if you want a single solution which will work across Python versions 2 and 3, you can use the following:
try:
reload # Python 2.7
except NameError:
try:
from importlib import reload # Python 3.4+
except ImportError:
from imp import reload # Python 3.0 - 3.3
I recommend using the following snippet as it works in all python versions (requires six):
from six.moves import reload_module
reload_module(module)
For python2 and python3 compatibility, you can use:
# Python 2 and 3
from imp import reload
reload(mymodule)
If you don't want to use external libs, then one solution is to recreate the reload method from python 2 for python 3 as below. Use this in the top of the module (assumes python 3.4+).
import sys
if(sys.version_info.major>=3):
def reload(MODULE):
import importlib
importlib.reload(MODULE)
BTW reload is very much required if you use python files as config files and want to avoid restarts of the application.....
import itertools
print itertools#ok
the code is ok
but i can't find the itertools file.
who can tell me where is the 'itertools file'
my code is run python2.5
import itertools
print itertools.__file__
Traceback (most recent call last):
File "D:\zjm_code\mysite\zjmbooks\a.py", line 5, in <module>
print itertools.__file__
AttributeError: 'module' object has no attribute '__file__'
>>> import itertools
>>> itertools.__file__
'/usr/lib64/python2.6/lib-dynload/itertools.so'
The fact that the filename ends with .so means it's an extension module written in C (rather than a normal Python module). If you want to take a look at the source code, download the Python source and look into Modules/itertoolsmodule.c (you can also view it in your browser at http://svn.python.org/view/python/trunk/Modules/itertoolsmodule.c?view=log).
Edit (as an answer to the comment below): it also works with Python 2.5:
Python 2.5.2 (r252:60911, Oct 5 2008, 19:29:17)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import itertools
>>> itertools.__file__
'/usr/lib/python2.5/lib-dynload/itertools.so'
If you're looking for the source file (in C, of course), it's for example online here.
For the windows users (I'm running Python 2.7.2, Win7x64, default installer package) the call to __file__ will flame out as #zjm1126 has noted, I suspect the problem being that itertools is a builtin on the windows package. If you'd picked say, exceptions? You'd get the same behaviour on another platform (e.g. Python 2.6.1 on my macbook) - Windows just happens to have a few more builtins like itertools.
It's not strictly an answer as such, but you could parse sys.modules which would give you a hint as to where it's coming from:
>>> import sys
>>> sys.modules['itertools']
<module 'itertools' (built-in)>
which points at itertools being built-in to your python executable.
Also, the imp.find_module response is providing the same information: the weird return tuple is by spec (see: http://docs.python.org/2/library/imp.html#imp.find_module) and telling you that the module is of type 6, which is the enumeration for imp.C_BUILTIN
try this
>>> import imp
>>> imp.find_module("itertools")
update:
since yours is None, another go through a manual way. Do a sys.path
>>> import sys
>>> sys.path
['', '/usr/lib/python2.6/lib-dynload' ]
then depending on your system, use your system's search facility to find it. on my linux system
$ find /usr/lib/python2.6/lib-dynload -type f -iname "*itertools*"
/usr/lib/python2.6/lib-dynload/itertoolsmodule.so
OR, just search the entire system for the file with name "itertools".