Maybe it is time to consider using virtualenv. Virtualenv creates self-contained python environments
using the python version you specify. After activating the new virtual environment, everything you install using pip goes under that environment. This helps avoid situations like the one you described.
E.g. create and activate a new python environment using the default python:
# create environment
$ virtualenv --distribute myproject
New python executable in myproject/bin/python
Installing distribute...done.
Installing pip...done.
# activate environment
$ . ./myproject/bin/activate
# check default python
(myproject)$ which python
/Users/me/myproject/bin/python
It is suggested to use the --distribute options to indicate that distribute should be used for installing packages in the new environment instead of (the older) setuptools. After activation your command prompt changes to indicate which python environment is active.
Now install some package. The files will go into myproject directory:
# install django
(myproject)$ pip install django
...
# search for django dir
(myproject)$ find myproject -iname django
myproject/lib/python2.7/site-packages/django
Finally, deactivate:
# deactivate and check for default python
(myproject)$ deactivate
$ which python
/usr/bin/python
To create an environment using a non-default version of python:
$ virtualenv --distribute -p /path/to/custom/python mynewproject
By default virtualenv will copy to the new environment any packages installed for the python version you use to bootstrap it. To prevent this and create an empty environment use the --no-site-packages option. This is especially useful to create environments which can be exactly replicated e.g. from development to production.
Update: As of version 1.7 --no-site-packages has become the default behaviour of virtualenv.
If you want more details, there are plenty of tutorials and blog posts online. E.g.:
- Notes on using pip and virtualenv with Django. (most of the post is not django-specific)
- Working with virtualenv.
Give it a try and I'm sure you'll stick with it.
Note: Make sure that your executable scripts do not have the python interpreter hardcoded. I.e. their first line should be #!/usr/bin/env python and not something like #!/usr/bin/python.
I had this exact error using CentOS 6.7 (Final) on a 64 bit system. I had to change two paths in order for python to work again. (Specifically gdb was giving me the same error you were getting.)
export PYTHONHOME=/usr/lib64/python2.6/
export PYTHONPATH=/usr/lib64/python2.6/
Other answers were saying to only modify one of those variables or use the non-64bit lib folder. But this was the only method that worked for me. Hopefully this can help someone else. In your case you might want to use the python2.7 folder however. But you can use python2.6 to get back to a working system at least.
Best Answer
First: This is normal.
.pycfiles are precompiled Python files. They contain the same data as the.pyfiles adjacent to them. If you are having problems with therandommodule, you are probably doing something else wrong, and you should probably ask a question about your code on Stack Overflow.More generally: You cannot, and should not, modify files under the
/Systemdirectory. They are part of the operating system -- modifying them will cause your computer to work incorrectly.macOS prevents system files from being modified (other than by system updates) using a mechanism called System Integrity Protection, or SIP. It is possible to disable SIP, but this should generally not be necessary, even for developers.