The location of standard Python libraries?
By default, the libraries are searched in prefix/lib/pythonversion and exec_prefix/lib/pythonversion , where prefix and exec_prefix are installation-dependent directories, both defaulting to /usr/local .
But when I looked into my /usr/local directory, what I found was a folder named python2.7. I did install python3.5 not python2.7 on my device (MacBook mid 2012).
3 Answers 3
You could use sys module to find that.
['', '/usr/local/lib/python2.7/dist-packages/mccabe-0.3.1-py2.7.egg', . I know that but I’m asking why standard library files are not where they are supposed to be. In addition to that, why do I have the python2.7 folder on my device?
Mac comes with a default Python 2.7 installation. Your installation did not remove python2.7. Probably also the reason why the system libraries are not under usr/local.
You never state how you attempted to install Python 3.5 onto your MacBook, depending on the installation options you used while building the Python source (or the bundle you downloaded) the install location could be different from the defaults. If you provide further details on your installation method, it will be easier to answer all aspects of your question.
As far as I can tell, Apple does not use the installation defaults to provide Python with OSX. On my OSX El Capitan machine, I can see the system Python library at /System/Library/Frameworks/Python.framework/Versions/2.7 and the binary at /usr/bin/python (Python 2.7.x comes preinstalled for all recent versions of OSX).
It looks like the easiest way to get Python 3.5 on Mac is to use MacPython which will install alongside the system version of Python (as you should not alter the default system version of Python or risk breaking OSX). It installs some helper applications into your Finder’s Applications directory and installs the library files to /System/Library/Frameworks/Python.framework/Versions/3.5. Since you will have more then one version of Python installed, you would also need to put some effort into making sure your scripts are using the proper version.
If you have a /usr/local/python2.7 directory, that sounds like something that was previously installed by a user. If I remember correctly, OSX does not normally use /usr/local for system software.
Where are the python modules stored?
If you import sys then run sys.path() , it shows all the paths for python. /usr/local/lib/python3.x/dist-packages worked for me.
In python 3.9, path is not a function, it’s A list of strings that specifies the search path for modules . docs
11 Answers 11
Usually in /lib/site-packages in your Python folder. (At least, on Windows.)
You can use sys.path to find out what directories are searched for modules.
If you want the location of a specific module, import it and look at it’s __file__ attribute. Works for most of them.
@NoufalIbrahim your answer is worth like the answer itself. TY. you can append it to make it bold for users.
On python command line, first import that module for which you need location.
For example to find out «pygal» location:
import pygal print(pygal.__file__) /anaconda3/lib/python3.7/site-packages/pygal/__init__.py Sample output of pip show tensorflow :
Name: tensorflow Version: 2.1.1 Summary: TensorFlow is an open source machine learning framework for everyone. Home-page: https://www.tensorflow.org/ Author: Google Inc. Author-email: packages@tensorflow.org License: Apache 2.0 Location: /home/user/.local/lib/python3.6/site-packages Requires: termcolor, six, astor, numpy, grpcio, absl-py, protobuf, tensorflow-estimator, tensorboard, gast, keras-applications, opt-einsum, wheel, keras-preprocessing, google-pasta, scipy, wrapt Required-by: tf-models-official The installed location is shown at Location:/home/user/.local/lib/python3.6/site-packages .
How do I find the location of Python module sources?
How do I learn where the source file for a given Python module is installed? Is the method different on Windows than on Linux? I’m trying to look for the source of the datetime module in particular, but I’m interested in a more general answer as well.
20 Answers 20
For a pure python module you can find the source by looking at themodule.__file__ . The datetime module, however, is written in C, and therefore datetime.__file__ points to a .so file (there is no datetime.__file__ on Windows), and therefore, you can’t see the source.
If you download a python source tarball and extract it, the modules’ code can be found in the Modules subdirectory.
For example, if you want to find the datetime code for python 2.6, you can look at
Python-2.6/Modules/datetimemodule.c You can also find the latest version of this file on github on the web at https://github.com/python/cpython/blob/main/Modules/_datetimemodule.c
If you edit your answer to indicate that datetime.__file__ points to a .so on Linux & Mac OS X (though on Windows the datetime module object has no file attribute), I’ll accept your answer.
Actually on Windows (at least on the version I’m using), datetime just doesn’t have a file attribute.
Running python -v from the command line should tell you what is being imported and from where. This works for me on Windows and Mac OS X.
C:\>python -v # installing zipimport hook import zipimport # builtin # installed zipimport hook # C:\Python24\lib\site.pyc has bad mtime import site # from C:\Python24\lib\site.py # wrote C:\Python24\lib\site.pyc # C:\Python24\lib\os.pyc has bad mtime import os # from C:\Python24\lib\os.py # wrote C:\Python24\lib\os.pyc import nt # builtin # C:\Python24\lib\ntpath.pyc has bad mtime . I’m not sure what those bad mtime’s are on my install!
Cool! You can also type in your own specific import statement after it opens up in interactive mode to see where the specific lib comes from.
I realize this answer is 4 years late, but the existing answers are misleading people.
The right way to do this is never __file__ , or trying to walk through sys.path and search for yourself, etc. (unless you need to be backward compatible beyond 2.1).
It’s the inspect module—in particular, getfile or getsourcefile .
Unless you want to learn and implement the rules (which are documented, but painful, for CPython 2.x, and not documented at all for other implementations, or 3.x) for mapping .pyc to .py files; dealing with .zip archives, eggs, and module packages; trying different ways to get the path to .so / .pyd files that don’t support __file__ ; figuring out what Jython/IronPython/PyPy do; etc. In which case, go for it.