Develop Reference

How can I ensure that my Python version is updated after installing version 3.11 using Mac?

I've just installed Python version 3.11 (I also moved versions 3.8 and 3.9 to the trash from my Applications folder).
I can see it in the following:
$ myname#name-MBP miniconda3 % ls /usr/local/bin/py*
/usr/local/bin/pydoc3 /usr/local/bin/python3-intel64
/usr/local/bin/pydoc3.11 /usr/local/bin/python3.11
/usr/local/bin/python3 /usr/local/bin/python3.11-config
/usr/local/bin/python3-config /usr/local/bin/python3.11-intel64
(Any additional recommendations on whether I need to clean things up would be much appreciated.)
Checking python3 --version still displays Python 3.8.13.
First attempt to solve
Initially I tried installing it from the command line using homebrew and specifying the version:
brew install python#3.11
I also tried using conda, but neither of these worked.
Second attempt to solve
My initial thought was to check my PATH (I think this is how Python decides which version to use, but please correct me if I'm wrong).
This still only contained version 8 paths:
/Users/myname/miniconda3/lib/python38.zip
/Users/myname/miniconda3/lib/python3.8
/Users/myname/miniconda3/lib/python3.8/lib-dynload
/Users/myname/.local/lib/python3.8/site-packages
/Users/myname/miniconda3/lib/python3.8/site-packages
So I added the Python3.11 path to it using
PYTHONPATH="/usr/local/bin/pydoc3.11/:$PYTHONPATH"
export PYTHONPATH
Now it includes the v3.11 path when I print out sys.path:
/usr/local/bin/python3.11
/usr/local/bin/pydoc3.11
/Users/myname/miniconda3
/Users/myname/miniconda3/lib/python38.zip
/Users/myname/miniconda3/lib/python3.8
/Users/myname/miniconda3/lib/python3.8/lib-dynload
/Users/myname/.local/lib/python3.8/site-packages
/Users/myname/miniconda3/lib/python3.8/site-packages
But the python3 --version output is still unchanged.
Questions
I'm nervous to keep playing around with the contents of my path and entering random command line executions to try to solve this because I really have no clue what I'm doing.
What's happening here?
How can I get the output of python3 --version to be 3.11?

So first thing to understand is setting the variable PYTHONPATH will not affect which version of python is executed by the shell. The shell (bash/zsh) only knows to scan the paths in the PATH env var to figure out all the executables.
Now there are two ways to solve this.
1. Using the python#3.11 from homebrew.
There are several downsides to using this method. Currently, the default python3 by brew is 3.10.x. Whenever you will install any cask or formula that depends on python#3, it'll invariably install the python#3 formula aka 3.10.x. Installing python3 will make brew symlink 3.10.x into /opt/homebrew/bin.
Python 3.11.x can be used by installing python#3.11 and invoking python3.11. This should drop you into the Python 3.11 interpreter. Append all python executable names with the version like pip will be pip3.11
Trying to force 3.11 over 3.10 links will be complicated and cause instability. It'll only cause frustration during development.
2. Using VirtualEnvs
Your best bet for the most stable and no-headache approach to python is to create virtual envs using either venv or pyenv. use pyenv-virtualenv for max ease of use.
One limitation of venv is that it'll create a virtualenv of the same version that invoked it. Aka if you do brew install python#3 && python3 -m venv <folder>, it'll create virtualenv of python3. For 3.11 you'll have to brew install python#3.11 && python3.11 -m venv <folder>. Pyenv on the other hand can install any version of python.
Go through https://www.dataquest.io/blog/a-complete-guide-to-python-virtual-environments/ and https://github.com/pyenv/pyenv-virtualenv to understand and learn more.

brew-installed Python not overriding system python

I just used brew to install Python 3 on OS X. The python3 command now starts the interpreter using brew Python 3.6, but python still opens the interpreter with the default system Python 2.7.
My understanding was that, by default, brew Python should now override system Python. (I.e., see Order of /usr/bin and /usr/local/bin and more in $PATH). In my PATH, /usr/local/bin comes before /usr/bin, so it shouldn't be a PATH issue. I have tried restarting Terminal, with no effect.
Here is my full PATH in case that is relevant.
/Users/**/.rvm/gems/ruby-1.9.3-p362/bin:/Users/**/.rvm/gems/ruby-1.9.3-p362#global/bin:/Users/**/.rvm/rubies/ruby-1.9.3-p362/bin:/Users/**/.rvm/bin:/Users/**/.rvm/bin:/Users/**/Python/PmagPy/programs/conversion_scripts2/:/Users/**/Python/PmagPy/programs/conversion_scripts/:/Users/**/Python/PmagPy/programs:/usr/local/heroku/bin:./bin:/usr/local/sbin:/usr/local/bin:/usr/local/share/npm/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/TeX/texbin:/opt/X11/bin
Why isn't brew Python taking precedence? And how can I fix (or troubleshoot) this? If I can't find another option, I can create an alias, but I prefer to understand what's happening and get to the root of the problem.
Update:
I checked out the "possible duplicate" question, but my issue doesn't appear to be a linking problem:
~ brew link --overwrite --dry-run python
Warning: Already linked: /usr/local/Cellar/python/3.6.4_4
To relink: brew unlink python && brew link python
~

TL;DR Add the following to your .bash_profile (or equivalent):
export PATH="/usr/local/opt/python/libexec/bin:$PATH"
Explanation
It seems python via homebrew is now handled differently (see https://docs.brew.sh/Homebrew-and-Python).
python3 points to Homebrew’s Python 3.x (if installed)
python2 points to Homebrew’s Python 2.7.x (if installed)
python points to Homebrew’s Python 2.7.x (if installed) otherwise the macOS system Python. Check out brew info python if you wish to add
Homebrew’s 3.x python to your PATH.
Checking out brew info python hints at what you need to do:
Unversioned symlinks python, python-config, pip etc. pointing to
python3, python3-config, pip3 etc., respectively, have been
installed into /usr/local/opt/python/libexec/bin
The hint being that you therefore have to add /usr/local/opt/python/libexec/bin before /usr/bin in your path (not /usr/local/bin as stated in some sources e.g. https://docs.python-guide.org/starting/install3/osx/)
See also https://github.com/Homebrew/homebrew-core/issues/15746

One-liner to get homebrew python working:
zsh
echo -n 'export PATH="/usr/local/opt/python/libexec/bin:$PATH"' >> ~/.zshrc && source ~/.zshrc
bash
echo -n 'export PATH="/usr/local/opt/python/libexec/bin:$PATH"' >> ~/.bashrc && source ~/.bashrc
Explanation:
>> filename appends at the end of the file
source filename reloads the file

I tried a few of the proposed solutions in How to link home brew python version and set it as default, but none of them worked. Ultimately I solved this by symlinking python3 --> python:
ln -s /usr/local/bin/python3 /usr/local/bin/python

Homebrew not linking python correctly?

I installed both python 2.7.13 and python 3.6.2 with homebrew and updated my ~/.bash_profile as such:
# Homebrew
export PATH=/usr/local/bin:$PATH
Python3 was linked fine. However, "which python" would still give me
/usr/bin/python
while "which python2" produces
/usr/local/bin/python2
It looks like homebrew installed python 2 as "python2" and never linked "python" to the new installation. This is causing me a lot of trouble down the road when installing virtualenvwrapper etc.
By the way, I also did
brew link python.
Anybody know why this is and how to fix it?
Much appreciated!!

They change that behavior here
Today I’d like to announce Homebrew 1.3.0. The most significant change
since 1.2.0 is that brew install python no longer installs a python
binary without manual PATH additions and instead installs a python2
binary. This avoids overriding the system python binary by default
when installing Python as a dependency. It also paves the way to
eventually have python be Python 3.x.
You will have to symlink python to the version of python installed by homebrew that you want.
You can do:
$ln -s /usr/local/bin/python2 /usr/local/bin/python
To symlink python to the homebrew Python2.x installation or do:
$ln -s /usr/local/bin/python3 /usr/local/bin/python
to link it to the Python 3.x hombrew installation.

gsi-frank's solution solves the problem quite well but after using his solution, you might encounter problems with your pip3. Your pip3 might be linked to the old instance and therefore unusable for your new python instance.
Type which pip3 to see where your pip3's path.
If your path is linked to your new instance, then ignore the rest of this answer.
Type echo $PATH to see your current path. If it contains your old python instance's path then you will need to remove it from your .bash_profile
To solve this: check your .bash_profile and see if there is a path to your old python instance.
If the old path is in there, you can delete it.
I had this problem and here's a link to the question if needed:
How to change pip3 path after installing python with homebrew?
To find your .bash_profile:
Go to your Finder
Right click and click Go to a folder... and type ~
Press CMD + shift + . to see hidden files
Right click your .bash_profile and open in a text editor

How to make Homebrew Python the main one I use? [duplicate]

I try to switch to Homebrew (after using fink and macport) on Mac OS X 10.6.2. I have installed python 2.7 with
brew install python
The problem is that, contrary to Macport, it seems that there is no python_select utility, and my default mac python is always default
which python
give me
/usr/bin/python
and /usr/bin/python is not a symlink
How can I do to make python brew flavour to be my default python ?

As suggested by the homebrew installer itself, be sure to add this to your .bashrc or .zshrc:
export PATH="/usr/local/opt/python/libexec/bin:$PATH"

As you are using Homebrew the following command gives a better picture:
brew doctor
Output:
==> /usr/bin occurs before /usr/local/bin This means that system-provided programs will be used instead of those provided by
Homebrew. This is an issue if you eg. brew installed Python.
Consider editing your .bash_profile to put: /usr/local/bin ahead of
/usr/bin in your $PATH.

See: How to symlink python in Homebrew?
$ brew link --overwrite python
Linking /usr/local/Cellar/python/2.7.3... 28 symlinks created
$ which python
/usr/local/bin/python

Quick fix:
Open /etc/paths
Change the order of the lines (highest priority on top)
In my case /etc/paths looks like:
/usr/local/bin
/usr/local/sbin
/usr/bin
/bin
/usr/sbin
/sbin
If you want to know more about paths in OSX I found this article quite useful:
http://muttsnutts.github.com/blog/2011/09/12/manage-path-on-mac-os-x-lion/

I did "brew install python" for OSX High Sierra. The $PATH had /usr/local/bin before any other path but still which python was pointing to the system's python.
When I looked deeper I found that there is no python executable at /usr/local/bin. The executable is named python2. To fix this problem create a symbolic link python pointing to python2:
/usr/local/bin $: ln -s python2 python

For Apple Silicon machines, the path are slightly different. After running brew install python, you must ensure your ~/.zshrc uses the correct Homebrew paths:
# Homebrew
eval "$(/opt/homebrew/bin/brew shellenv)"
# Homebrew: Python
export PATH="/opt/homebrew/opt/python/libexec/bin:$PATH"
Results:
% which python
/opt/homebrew/opt/python/libexec/bin/python
% python --version
Python 3.9.9
% which pip
/opt/homebrew/opt/python/libexec/bin/pip
% pip -V
pip 21.3.1 from /opt/homebrew/lib/python3.9/site-packages/pip (python 3.9)

python formula now uses python3(v3.6.5 for now), brew will link the directory:
/usr/local/opt/python -> ../Cellar/python/3.6.5
it will also link the binary:
/usr/local/bin/python3 -> ../Cellar/python/3.6.5/bin/python3
If you still need to use python2.x, use:
brew install python#2
To use homebrew's python, just put its directory in PATH, for bash:
export PATH="/usr/local/opt/python/libexec/bin:$PATH"
for fish:
set -x PATH /usr/local/opt/python/libexec/bin $PATH
Note:
doing this will shadow the system default version of python
homebrew used to link python to /usr/local/share/python in older versions.

Homebrew does NOT replace stuff in "/usr/bin". You'll just want to put "/usr/local/bin" ahead of "/usr/bin" in your path, then "which python" will give you "/usr/local/bin/python".
Replacing /usr/bin/python (or /usr/bin/ruby) is highly unrecommended.

Modify your $PATH, Add this in your bashrc or bash_profile:
export PATH=/usr/local/bin:/usr/local/sbin:~/bin:$PATH
more click here:
Issue #89791

I did brew install python, my $PATH was good, but still, which python gave me the system installed one. Restarting the terminal fixed it.

You need to edit your PATH environmental variable to make sure wherever the homebrew python is located is searched before /usr/bin. You could also set things up in your shell config to have a variable like PYTHON be set to your desired version of python and call $PYTHON rather than python from the command line.
Also, as another poster stated (and especially on mac) DO NOT mess with the python in /usr/bin to point it to another python install. You're just asking for trouble if you do.

python now points to python3, if you need python 2 then do:
brew install python#2 and then in your .zshrc or .bashrc file
export PATH="/usr/local/opt/python#2/libexec/bin:$PATH"
Now, pyhon --version = Python 2.7.14 and python3 --version = Python 3.6.4.
That's the behavior I'm used to seeing in my terminal.

I believe there are means to make homebrew python default, but in my opinion the proper way to solve a problem is not to mess with system python paths: it is better to create a virtualenv in which homebrew python would be default (by using virtualenv --python option). Using tools like python_select is almost always a bad idea.

Use pyenv instead to install and switch between versions of Python. I've been using rbenv for years which does the same thing, but for Ruby. Before that it was hell managing versions.
Consult pyenv's github page for installation instructions. Basically it goes like this:
- Install pyenv using homebrew. brew install pyenv
- Add a function to the end of your shell startup script so pyenv can do it's magic. echo -e 'if command -v pyenv 1>/dev/null 2>&1; then\n eval "$(pyenv init -)"\nfi' >> ~/.bash_profile
Use pyenv to install however many different versions of Python you need. pyenv install 3.7.7.
Set the default (global) version to a modern version you just installed. pyenv global 3.7.7.
If you work on a project that needs to use a different version of python, look into pyevn local. This creates a file in your project's folder that specifies the python version. Pyenv will look override the global python version with the version in that file.

Add the /usr/local/opt/python/libexec/bin explicitly to your .bash_profile:
export PATH="/usr/local/opt/python/libexec/bin:$PATH"
After that, it should work correctly.

Just do:
brew install python
brew link python
After doing that, add this to your bashrc or bash_profile:
alias python='/usr/local/bin/python2'
Enjoy!

You can edit /etc/paths. Here is mine:
/usr/local/bin
/usr/bin
/bin
/usr/sbin
/sbin
Then add a symlink for the python version. In my case
$ cd /usr/local/bin
$ ln -s python3 python
Voila!

If you are fish shell
echo 'set -g fish_user_paths "/usr/local/opt/python/libexec/bin" $fish_user_paths' >> ~/.config/fish/config.fish

try this
which python3
Try typing python3 instead of just python

Greeting folks! I have the need to use python 3.10 version to harness its new features. My solved solution at 2022-07-03 is as follows. Have fun coding python!
» rm '/usr/local/bin/pip3.10'
» brew link python#3.10
» echo 'export PATH="/usr/local/opt/python#3.10/bin:$PATH"' >> ~/.zshrc
» python3
Python 3.10.5 (main, Jun 23 2022, 17:15:25) [Clang 13.1.6 (clang-1316.0.21.2.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

Since High Sierra, you need to use:
sudo chown -R $(whoami) $(brew --prefix)/*
This is because /usr/local can no longer be chowned

brew link python
And you must create/add an alias for python and put it in your .zprofile (Located in Users/username folder, if you press Shift+command+.
This must point to your homebrew python installation location.
alias python ='opt/homebrew/bin/python3'

No idea what you mean with default Python. I consider it bad practice to replace the system Python interpreter with a different version. System functionality may depend in some way on the system Python and specific modules or a specific Python version. Instead install your custom Python installations in a safe different place and adjust your $PATH as needed in order to call you Python through a path lookup instead of looking for the default Python.

Problem with virtualenv in Mac OS X

I've installed virtualenv via pip and get this error after creating a new environment:
selenium:~ auser$ virtualenv new
New python executable in new/bin/python
ERROR: The executable new/bin/python is not functioning
ERROR: It thinks sys.prefix is u'/System/Library/Frameworks/Python.framework/ Versions/2.6' (should be '/Users/user/new')
ERROR: virtualenv is not compatible with this system or executable
In my environment:
PYTHONPATH=/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages
PATH=/System/Library/Frameworks/Python.framework/Versions/2.6/bin:/Library/Frameworks/Python.framework/Versions/2.6/bin:/Library/Frameworks/Python.framework/Versions/2.6/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin
How can I repair this?
Thanks.

Just in case there's someone still seeking for the answer.
I ran into this same problem just today and realized since I already have Anaconda installed, I should not have used pip install virtualenv to install virtual environment as this would give me the error message when trying to initiate it later. Instead, I tried conda install virtualenv then entered virtualenv env_mysite and problem solved.

Like #RyanWilcox mentioned, you might be inadvertently pointing virtualenv to the wrong Python installation. Virtualenv comes with a -p flag to let you specify which interpreter to use.
In my case,
virtualenv test_env
threw the same error as yours, while
virtualenv -p python test_env
worked perfectly.
If you call virtualenv -h, the documentation for the -p flag will tell you which python it thinks it should be using; if it looks wonky, try passing -p python. For reference, I'm on virtualenv 1.11.6.

In case anyone in the future runs into this problem - this is caused by your default Python distribution being conda. Conda has it's own virtual env set up process but if you have the conda distribution of python and still wish to use virtualenv here's how:
Find the other python distribution on your machine: ls -ls /usr/bin/python*
Take note of the availble python version that is not conda and run the code below (note for python 3 and above you have to upgrade virtualenv first): virtualenv -p python2.7(or your python version) flaskapp

I've run across this problem myself. I wrote down the instructions in a README, which I have pasted below....
I have found there are two things that work:
Make sure you're running the latest virtualenv (1.5.1, of this writting)
If you're using a non system Python as your standard Python (which python to check) Forcefully use the System supplied one.
Instead of virtualenv thing use /usr/bin/python2.6 PATH/TO/VIRTUALENV thing (or whatever which
python returned to you - this is what it did for me when I ran into this issue)

I had the same problem and as I see it now, it was caused by a messy Python installation. I have OS X installed for over a year since I bought a new laptop and I have already installed and reinstalled Python for several times using different sources (official binaries, homebrew, official binaries + hand-made adjustments as described here). Don't ask me why I did that, I'm just a miserable newbie believing everything will fix itself after being re-installed.
So, I had a number of different Pythons installed here and there as well as many hardlinks pointing at them inconsistently. Eventually I got sick of all of them and reinstalled OS X carefully cleaned the system from all the Pythons I found using find utility. Also, I have unlinked all the links pointing to whatever Python from everywhere. Then I've installed a fresh Python using homebrew, installed virtualenv and everything works as a charm now.
So, my recipe is:
sudo find / -iname "python*" > python.log
Then analyze this file, remove and unlink everything related to the version of Python you need, reinstall it (I did it with homebrew, maybe official installation will also work) and enjoy. Make sure you unlink everything python-related from /usr/bin and /usr/local/bin as well as remove all the instances of Frameworks/Python.framework/Versions/<Your.Version> in /Library and /System/Library.
It may be a dirty hack, but it worked for me. I prefer not to keep any system-wide Python libraries except pip and virtualenv and create virtual environments for all of my projects, so I do not care about removing the important libraries. If you don't want to remove everything, still try to understand whether your Pythons are, what links point to them and from where. Then think what may cause the problem and fix it.

I ran into a variation of this "not functioning" error.
I was trying to create an environment in a folder that included the path ".../Programming/Developing..." which is actually "/Users/eric/Documents/Programming:Developing/"
and got this error:
ImportError: No module named site
ERROR: The executable env/bin/python2.7 is not functioning
ERROR: It thinks sys.prefix is u'/Users/eric/Documents/Programming:Developing/heroku' (should be u'/Users/eric/Documents/Programming:Developing/heroku/env')
ERROR: virtualenv is not compatible with this system or executable
I tried the same in a different folder and it worked fine, no errors and env/bin has what I expect (activate, etc.).

I got the same problem and I found that it happens when you do not specify the python executable name properly. So for python 2x, for example:
virtualenv --system-site-packages -p python mysite
But for python 3.6 you need to specify the executable name like python3.6
virtualenv --system-site-packages -p python3.6 mysite

On on OSX 10.6.8 leopard, after having "upgraded" to Lion, then downgrading again (ouch - AVOID!), I went through the Wolf Paulus method a few months ago, completely ignorant of python. Deleted python 2.7 altogether and "replaced" it with 3.something. My FTP program stopped working (Fetch) and who knows what else relies on Python 2.7. So at that point I downloaded the latest version of 2.7 from python.org and it's installer got me up and running - until i tried to use virtualenv.
What seems to have worked for me this time was totally deleting Python 2.7 with this code:
sudo rm -R /System/Library/Frameworks/Python.framework/Versions/2.7
removing all the links with this code:
sudo rm /usr/bin/pydoc
sudo rm /usr/bin/python
sudo rm /usr/bin/pythonw
sudo rm /usr/bin/python-config
I had tried to install python with homebrew, but apparently it will not work unless all of XTools is installed, which I have been avoiding, since the version of XTools compatible with 10.6 is ancient and 4GB and mostly all I need is GCC, the compiler, which you can get here.
So I just installed with the latest download from python.org.
Then had to reinstall easy_install, pip, virtualenv.
Definitely wondering when it will be time for a new laptop, but there's a lot to be said for buying fewer pieces of hardware (slave labor, unethical mining, etc).

The above solutions failed for me, but the following worked:
python3 -m venv --without-pip <ENVIRONMENT_NAME>
. <ENVIRONMENT_NAME>/bin/activate
curl https://bootstrap.pypa.io/get-pip.py | python
deactivate
It's hacky, but yes, the core problem really did just seem to be pip.

I did the following steps to get virtualenv working :
Update virtualenv as follows :
==> sudo pip install --upgrade virtualenv
Initialize python3 virtualenv :
==> virtualenv -p python3 venv

I had this same issue, and I can confirm that the problem was with an outdated virtualenv.py file.
It was not necessary to do a whole install --upgrade.
Replacing the virtualenv.py file with the most recent version sufficed.

I also had this problem, and I tried the following method which worked for me:
conda install virtualenv
virtualenv --system-site-packages /anaconda/envs/tensorflow (here envs keeps all the virtual environments made by user)
source /anaconda/envs/tensorflow/bin/activate
Hope it's helpful.

I had this same issue when trying to install py2.7 on a newer system. The root issue was that virtualenv was part of py3.7 and thus was not compatible:
$ virtualenv -p python2.7 env
Running virtualenv with interpreter /usr/local/bin/python2.7
New python executable in /Users/blah/env/bin/python
ERROR: The executable /Users/blah/env/bin/python is not functioning
ERROR: It thinks sys.prefix is u'/Library/Frameworks/Python.framework/Versions/2.7' (should be u'/Users/blah/env')
ERROR: virtualenv is not compatible with this system or executable
$ which virtualenv
/Library/Frameworks/Python.framework/Versions/3.7/bin/virtualenv
# install proper version of virtualenv
$ pip2.7 install virtualenv
$ /Library/Frameworks/Python.framework/Versions/2.7/bin/virtualenv -p python2.7 env
$ . ./env/bin/activate
(env) $

Open terminal and type /Library/Frameworks/Python.framework/Versions/
then type ls /Library/Frameworks/Python.framework/Versions/2.7/bin/
if you are using Python2(or any other else).
Edit ~/.bash_profile and add the following line:
export PATH=$PATH:/Library/Frameworks/Python.framework/Versions/2.7/bin/
cat ~/.bash_profile
In my case the content of ~/.bash_profile is as follows:
export PATH=$PATH:/Library/Frameworks/Python.framework/Versions/2.7/bin/
Now the virtualenv command should work.

If you continue to have trouble with virtualenv, you might try pythonbrew, instead. It's an alternate solution to the same problem. It works more like Ruby's rvm: It builds and creates an entire instance of Python, under $HOME/.pythonbrew, and then sets up some bash functions that allow you to switch easily between versions. Where virtualenv shadows the system version of Python, using symbolic links as part of its solution, pythonbrew builds entirely self-contained installations of Python.
I used virtualenv for years. It's a decent solution, but I've switched to pythonbrew lately. Having completely self-contained Python instances means that installing a new one takes awhile (since pythonbrew actually compiles Python from scratch), but the self-contained nature of each installation appeals to me. And disk is cheap.