The following commands will remove your make altinstall-ed python:

rm -f /usr/local/bin/python2.7
rm -f /usr/local/bin/pip2.7
rm -f /usr/local/bin/pydoc
rm -rf /usr/local/bin/include/python2.7
rm -f /usr/local/lib/libpython2.7.a
rm -rf /usr/local/lib/python2.7

You might also have to do

rm -f /usr/local/share/man/python2.7.1
rm -rf /usr/local/lib/pkgconfig
rm -f /usr/local/bin/idle
rm -f /usr/local/bin/easy_install-2.7

Although make altinstall has served me well if the "system python" has a different major.minor number from the one you install, it doesn't work that well if only the micro number (the third position) differs. That number is excluded from the installed binary, and you end up with two versions pythonX.Y. This was always a problem but once distributions started shipping with system utilities based on 2.7.X this problem has been more severe as 2.7 is supposed to be the last of the Python2 series.

IMO the best approach to solve this problem is to prevent it from becoming one: configure python to install in a directory not used by any other python. On my system they go under /opt/python/X.Y.Z.

To use any of the Pythons installed there you use [virualenv][1] to make a new environment:

virtualenv --python=/opt/python/2.7.9/bin/python2.7 venv
source venv/bin/activate

or use [virtualenvwrapper][2]. I have some aliases for the latest versions in the series I work with.

If you are using tox for testing against multiple versions (you should) the following alias will help it find the various version:

alias tox='PATH=/opt/python/2.7.9/bin:/opt/python/2.6.9/bin:/opt/python/3.4.3/bin:/opt/python/3.3.6/bin:/opt/python/3.5-dev/bin:$PATH tox'

(these are currently the latest versions, I use a slightly different setup by maintaining links from /opt/python/2.7 to the latest /opt/python/2.7.9, and for the other minor numbers as well, within the process for downloading, building and installing a new python version)

These installs are never used directly. They are always used as the basis for virtualenv environments only, hence I don't care that they are not in my normal PATH.

The following commands will remove your make altinstall-ed python:

rm -f /usr/local/bin/python2.7
rm -f /usr/local/bin/pip2.7
rm -f /usr/local/bin/pydoc
rm -rf /usr/local/include/python2.7
rm -f /usr/local/lib/libpython2.7.a
rm -rf /usr/local/lib/python2.7

You might also have to do

rm -f /usr/local/share/man/python2.7.1
rm -rf /usr/local/lib/pkgconfig
rm -f /usr/local/bin/idle
rm -f /usr/local/bin/easy_install-2.7

Although make altinstall has served me well if the "system python" has a different major.minor number from the one you install, it doesn't work that well if only the micro number (the third position) differs. That number is excluded from the installed binary, and you end up with two versions pythonX.Y. This was always a problem but once distributions started shipping with system utilities based on 2.7.X this problem has been more severe as 2.7 is supposed to be the last of the Python2 series.

IMO the best approach to solve this problem is to prevent it from becoming one: configure python to install in a directory not used by any other python. On my system they go under /opt/python/X.Y.Z.

To use any of the Pythons installed there you use [virualenv][1] to make a new environment:

virtualenv --python=/opt/python/2.7.9/bin/python2.7 venv
source venv/bin/activate

or use [virtualenvwrapper][2]. I have some aliases for the latest versions in the series I work with.

If you are using tox for testing against multiple versions (you should) the following alias will help it find the various version:

alias tox='PATH=/opt/python/2.7.9/bin:/opt/python/2.6.9/bin:/opt/python/3.4.3/bin:/opt/python/3.3.6/bin:/opt/python/3.5-dev/bin:$PATH tox'

(these are currently the latest versions, I use a slightly different setup by maintaining links from /opt/python/2.7 to the latest /opt/python/2.7.9, and for the other minor numbers as well, within the process for downloading, building and installing a new python version)

These installs are never used directly. They are always used as the basis for virtualenv environments only, hence I don't care that they are not in my normal PATH.

The following commands will remove your make altinstall-ed python:

rm -f /usr/local/bin/python2.7
rm -f /usr/local/bin/pip2.7
rm -f /usr/local/bin/pydoc
rm -rf /usr/local/bin/include/python2.7
rm -f /usr/local/lib/libpython2.7.a
rm -rf /usr/local/lib/python2.7

You might also have to do

rm -f /usr/local/share/man/python2.7.1
rm -rf /usr/local/lib/pkgconfig
rm -f /usr/local/bin/idle
rm -f /usr/local/bin/easy_install-2.7

Although make altinstall has served me well if the "system python" has a different major.minor number from the one you install with it. It doesn't work that well if only the micro number (the third postiion) differs. That number is excluded from the installed binary, and you end up with two versions pythonX.Y. This was always a problem but once distributions started shipping with system utilities based on 2.7.X this problem has been more severe as 2.7 is supposed to be the last of the Python2 series.

IMO the best approach to solve this problem is to prevent it from becoming one: configure python to install in a directory not used by any other. On my system they go under /opt/python/X.Y.Z.

To use any of the Pythons installed there you use [virualenv][1] to make a new environment:

virtualenv --python=/opt/python/2.7.9/bin/python2.7 venv
source venv/bin/activate

or use [virtualenvwrapper][2]. I have some aliases for the latest versions in the series I work with.

If you are using tox for testing against multiple versions (you should) the following alias will help it find the various version:

alias tox='PATH=/opt/python/2.7.9/bin:/opt/python/2.6.9/bin:/opt/python/3.4.3/bin:/opt/python/3.3.6/bin:/opt/python/3.5-dev/bin:$PATH tox'

(these are currently the latest versions, I use a slightly different setup by maintaining links from /opt/python/2.7 to the latest /opt/python/2.7.9, and for the other minor numbers as well, within the process for downloading, building and installing a new python version)

These installs are never used directly. They are always used as the basis for virtualenv environments only, hence I don't care that they are not in my normal PATH.

The following commands will remove your make altinstall-ed python:

rm -f /usr/local/bin/python2.7
rm -f /usr/local/bin/pip2.7
rm -f /usr/local/bin/pydoc
rm -rf /usr/local/bin/include/python2.7
rm -f /usr/local/lib/libpython2.7.a
rm -rf /usr/local/lib/python2.7

You might also have to do

rm -f /usr/local/share/man/python2.7.1
rm -rf /usr/local/lib/pkgconfig
rm -f /usr/local/bin/idle
rm -f /usr/local/bin/easy_install-2.7

Although make altinstall has served me well if the "system python" has a different major.minor number from the one you install, it doesn't work that well if only the micro number (the third position) differs. That number is excluded from the installed binary, and you end up with two versions pythonX.Y. This was always a problem but once distributions started shipping with system utilities based on 2.7.X this problem has been more severe as 2.7 is supposed to be the last of the Python2 series.

IMO the best approach to solve this problem is to prevent it from becoming one: configure python to install in a directory not used by any other python. On my system they go under /opt/python/X.Y.Z.

To use any of the Pythons installed there you use [virualenv][1] to make a new environment:

virtualenv --python=/opt/python/2.7.9/bin/python2.7 venv
source venv/bin/activate

or use [virtualenvwrapper][2]. I have some aliases for the latest versions in the series I work with.

If you are using tox for testing against multiple versions (you should) the following alias will help it find the various version:

alias tox='PATH=/opt/python/2.7.9/bin:/opt/python/2.6.9/bin:/opt/python/3.4.3/bin:/opt/python/3.3.6/bin:/opt/python/3.5-dev/bin:$PATH tox'

(these are currently the latest versions, I use a slightly different setup by maintaining links from /opt/python/2.7 to the latest /opt/python/2.7.9, and for the other minor numbers as well, within the process for downloading, building and installing a new python version)

These installs are never used directly. They are always used as the basis for virtualenv environments only, hence I don't care that they are not in my normal PATH.