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.

How can I change the Python interpreter in virtual environment (Ubuntu 18.04LTS)?

I always used Anaconda on Windows so far and could set up an environment while choosing which exact Python to use. E.g. conda create -n myEnvName python=3.7
Now, I want to familiarize with Ubuntu 18.04 LTS and use basic Python environments.
So I followed these steps:
Created folder in my home = ~/.venvPython
(a) I think I already had a 2.7 and 3.6 by default on the OS.
(b) I do not remember for sure, I think I had to do this sudo apt-get install python3-venv.
Created environment this way after CD'ing to .venvPython folder ran this: python3 -m venv venv1BigDataPgm2
source ~/.venvPython/venv1BigDataPgm2/bin/activate
Command python --version says: Python 3.6.9
Running whereis Python shows this:
rohit#rohitUb18043LTS:~$ whereis python
python: /usr/bin/python3.6 /usr/bin/python3.6-config /usr/bin/python2.7-config /usr/bin/python3.6m-config /usr/bin/python /usr/bin/python3.6m /usr/bin/python2.7 /usr/lib/python3.8 /usr/lib/python3.7 /usr/lib/python3.6 /usr/lib/python2.7 /etc/python3.6 /etc/python /etc/python2.7 /usr/local/lib/python3.6 /usr/local/lib/python2.7 /usr/include/python3.6 /usr/include/python3.6m /usr/include/python2.7 /usr/share/python /usr/share/man/man1/python.1.gz
My doubts:
Can I specify a Python version directly while creating the environment like with conda?
How do I change this to some other interpreter instead of the 3.6.9?
Do I have to manually install a different Python first, then point it somehow?
Please guide me. Thank you.
Rohit

As far as I can tell the venv standard library appeared in Python 3.3 and was never backported to 2.7.
venv can only create virtual environment for its own version of the interpreter and the virtual environment directory can not be moved to a different location or be renamed. Python 3.foo can not create a virtual environment for Python 3.bar. So it is best to pick the wanted interpreter right from the start.
Since, as shown by the output of whereis python, you seem to already have multiple Python interpreters already installed, you should be able to do something like the following:
$ /path/to/python3.3 -m venv /path/to/my/venvs/venv33
$ /path/to/python3.8 -m venv /path/to/my/venvs/venv38
There seems to be a way to change the Python interpreter associated with a virtual environment (I have not tested it, not sure what the limitations are):
$ /path/to/python3.8 -m venv --upgrade /path/to/my/venvs/venv33
Alternatively use virtualenv which seems to offer a bit more flexibility, but is probably less efficient (its next major release, virtualenv 20, should bring a lot of improvements though).

Ubuntu and other Debian-based systems generally ship whichever Python version was current and deemed sufficiently tested when the release was published; after that, only security updates which preserve the version number but add patches are released (so you might get 3.6.9-123security4 instead of 3.6.9-5 or whatever was current when the release was cut).
If you want to run a specific Python version on one of these platforms, see if you can find an Apt source which provides this version for your system (Ubuntu has a soft underbelly of unofficial PPAs of various repute; Debian has backports) or install it from source yourself. There are add-ons like pyenv which let you do this rather easily, safely, and transparently.
There may also be an existing package which gives you a particular newer version; for example, you can do apt install python3.7 and apt install python3.8 on Ubuntu 18.04, but there are no packages for 3.5 or 3.9. Try apt policy python3.7 to see which specific minor version is available from the Ubuntu package archive.

An alternative to that is to always specify the python version you wish use when running a script.
python3.6 test_script.py

Usually, when I'm on Linux and don't need a specific python3 version, I create native python3 environments.
python3 -m venv myenv
source myenv/bin/activate
But if I need a specific python3 version, I do:
python3.9 -m venv myenv
source myenv/bin/activate
To use a specific python3 version with native environments, you have to install that version using the native package manager (eg. apt).

Python: Install VirtualEnv for both Python 2 and Python 3

After moving over to Fedora (from Windows), I realized that it came with both installations of Python 2.7.5 and Python 3.6.6.
As I familiarized myself with using Python, I learned of the great utilities of virtual environments and how organized they keep everything.
However, my current dilemma is for which Python version should I do pip(2 or 3) install virtualenv virtualenvwrapper.
From my research, I understand that the virtualenvwrapper provides the ability to create a virtual environment using a specified version of Python: mkvirtualenv -p /usr/bin/python(2 or 3) {name}.
Therefore, should I only install virtualenv and virtualenvwrapper on one of the Python versions and use the aforementioned feature? Or should I install virtualenv and virtualenvwrapper on both versions of Python.
Would there be any conflicts?
Edit
More importantly, assuming that I have virtualenv and virtualenvwrapper installed for both Python 2.7.5 and Python 3.6.6, which version's command is called when I run any of the following: workon, mkvirtualenv, rmvirtualenv, etc.?

Would there be any conflicts?
Not until you mistakenly run the default system python command with a script that's using the opposite version as compared to the more specific python2 or python3 commands.
The virtualenvs do not conflict, and must be activated to be used. You can also of course have as many virtualenv's as you wish.
To avoid any problems setting up an environment, its suggested to run python2 -m virtualenv for example, rather than simply virtualenv command itself
For the commands listed at the bottom of the question, it depends on how your PATH is configured. Personally, I use pyenv rather than virtualenv directly, which injects itself into the OS PATH variable

Python versions on Linux

Yesterday i reinstalled my Linux Mint duo similar issue I am facing right now.
I installed Python 3.6 with:
apt-get install build-essential checkinstall libreadline-gplv2-dev libncursesw5-dev libssl-dev libsqlite3-dev tk-dev libgdbm-dev libc6-dev libbz2-dev
cd /usr/src
wget https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tgz
tar xzf Python-3.6.0.tgz
cd Python-3.6.0
./configure
make altinstall
python3.6 -V
And then, there is Python 2.7.12 on Linux as default, which i can see by:
python -V
Python 2.7.12
When i check:
python3 -V
My output is:
Python 3.5.2
However:
python3.6 -V
Python 3.6.0
I also downloaded and installed Pycharm but the problem is, Project Interpreter can't find Python 3.6, i also can't add Python 3.6 manually in any way.
I've noticed that other Python versions PATHs in PyCharm looks like:
/usr/bin/python2.7
/usr/bin/python3.5
But i can't find any Python 3.6 in there.
One more thing - When i checked:
/usr/local/lib/python3.5/dist-packages
It's the only folder i can find there, it was empty but when i tried to do something with pip, it automatically saved there.
However:
/usr/local/lib/python3.6
does not contain such a folder. As i remember, it was the folder where all modules were installed.
1) Is Python 3.6 installed correctly, if not, how to fix that?
2) How the hell Python 3.5.2 has been installed there and should i delete it?
3) How to make PyCharm working on Python 3.6
4) Python 3.5 will cause problems with installing modules, I had same issue before reinstall of my Linux. What's wrong here?

What is the output of the command:
$ update-alternatives --list python3
on your system?
Does it look like:
/usr/bin/python3.5
/usr/bin/python3.6
If so you can use the command:
$ sudo update-alternatives --config python3
to choose which python3 version to run. However, be warned, some of your installed software may depend on version 3.5 and changing the default python3 could have side effects. You should be able to update to python3.6 for your default and then install the packages you need, switching back to 3.5 as the default when you want to.
However, you will constantly be swapping your defaults, and sooner or later you will probably forget and get into some kind of versioning conflict.
Depending on your specific needs for python3.6, you can use it selectively only when you need it.
Here are some examples...
1) When working at the command line, start your python session with 'python3.6' instead of 'python3' and you will be using 3.6 instead of 3.5.
2) When writing python executables, use the shebang line '#! /usr/bin/python3.6' instead of '#! /usr/bin/python3' to ensure you are using python 3.6
3) when running a python file at the command line use
'python3.6 file_name.py'
or
'python3.5 file_name.py'
as needed to call the specific version of python you need.
These are all cumbersome, but relatively safe. You will only be using 3.6 when you need it.
The best way to keep your system safe, support multiple versions of python, and not break any system dependencies on the 3.5 release, is to learn about virtual environments. These are environments that use their own specified version of python, and the specific packages for their environment.
Virtual environments are a little complicated at first, but once you get the hang of them it is nice to have a few separate projects, each with slightly different sets of dependencies, all in their own footprints and not stepping on each other.
Here are some tutorials:
http://docs.python-guide.org/en/latest/dev/virtualenvs/
https://realpython.com/python-virtual-environments-a-primer/
https://docs.python.org/3/tutorial/venv.html
There are plenty of tutorials on youtube as well.
Good luck and happy coding!

"Proper way" to manage multiple versions of Python on archlinux

So I have read this - https://wiki.archlinux.org/index.php/Python
And it is clear from this wiki that I can install Python 2.7.2 via
pacman -S python2
Is it reasonable for me to create a symlink to python2
ln -s python2 /usr/bin/python
if I don't forsee myself switching to python 3.0 any time soon? Or is there a better way of managing multiple python versions like what I usually use on a debian system (update-alternatives --config python) or on a mac os x system (python select)?
CLARIFICATION:
What I am trying to find out is - what is the "best practice" of managing various python versions on an archlinux system?
I am new to archlinux but familiar with ubuntu, debian and mac os x

I would argue you shouldn't create any symlinks like this at all. Especially if you are going to distribute some of your python code, you should not assume a user has python2 or python3 at /usr/bin/python.
If your script requires python2, just use:
#!/usr/bin/env python2
If your script requires python3, use:
#!/usr/bin/env python3
This way your scripts will work fine even through updates to Python. It will also be much more clear what version your script actually needs.

Most unices already have a /usr/bin/python. Overwriting that one is a bad idea, as this is the Python version used by all packages in the system, and changing that one may break them. When installing the Python 2.7 package the executable should be installed as /usr/bin/python2.7 (if not I would claim Archlinux is broken) and it's better to use that when you want to run Python 2.7.
Archlinux is a bit special, since it will use /usr/bin/python for Python 3, despite the default executable name for Python 3 being /usr/bin/python3. This is confusing and can be seen as a bug, but it does mean you can't use that symlink for Python 2, as any other Archlinux script that uses Python 3 will almost certainly break if you do.
So where on other Unices, symlinking /usr/bin/python to Python 2.7 is a bad idea, on Archlinux it is a terrible idea. Instead just install all version you need and call them with /usr/bin/pythonX.X.

There is a nice project on github what helps you with it's called pyenv
What helps you to manage multiple python instances

As others have said, the short answer is "don't do this, it will most likely break things on your system", however, if you mostly use Python 2 you can still set your personal default in your shell (and still have the option of switching to Python 3 at any time). To do this, first become root and install python2-virtualenv:
# pacman -S python2-virtualenv
Then create a virtual environment that uses Python 2 (this will automatically install Python, setuptools, wheel, and pip in the environment):
$ virtualenv -p /usr/bin/python2 --system-site-packages ~/env # (Or wherever you want your environment to live)
If you only want to use locally installed packages (eg. packages you install with pip and not the ones installed by pacman) remove the --system-site-packages option when creating your environment.
Now in your ~/.bash_profile or ~/.profile (or whatever your preferred shells configuration file is), set something like the following:\
source ~/env/bin/activate
This will activate the virtual environment, making your default version Python 2.
This could still break anything that is launched in a shell, but it's not likely that anything will be unless you're explicitly running it from a shell, at which point you can turn the virtual environment off by running:
deactivate
or simply manually run Python 3.

I just stumbled over this post, no necro-bumping intended but I was wondering nobody mentioned virtualenvs. I'm using ArchLinux as well and I use the python packages virtualenv and virtualenvwrapper to create multiple python environments. You can reference to the python 2 or python3 binaries in /usr/bin/ to determine the python version used in the virtual environment.
The benefit is that packages installed in a virtual environment don't mess with the python the system is using and there are many ways to automate project handling.

I know this may be a very old answer, but it took me two days to solve the problem so I'm going to share.
The proper way to manage python versions in your system to work on different projects without them driving you crazy is to use pyenv and its plugins pyenv-virtualenv and pyenv-virtualenvwrapper as described by Henrique Bastos into this blog post. Notice that this way to work is kinda platform independent, since pyenv is a python package and it can be run quite similarly on Windows, Linux and Mac OSx.
The problems start with Arch Linux. The OS doesn't provide a pacman version of pyenv, so you have to install it cloning it from github as described in the installation section of the release. The installation process is the same both for pyenv-virtualenv and pyenv-virtualenvwrapper. Notice that the shell initialization configuration may be different, in my case it didn't work for ~/.bash_profile, but worked for ~/.bashrc .
Running pyenv is not straightforward if your installation is very fresh like the one I'm setting up in these days, since pip requires openSSL and even if you install it via pacman, pyenv doesn't see it. So, if you want to install an older version of Python (namely 3.4.3), you will find the shell complaining about you haven't installed the openSSL plugin, even if you have it. To be honest, I didn't have the right packages the first time I tried to install it; you have to download the following packages
sudo pacman -S openssl
sudo pacman -S openssl-1.0
sudo pacman -S python-pyopenssl
sudo pacman -S python2-pyopenssl
The way I solved the problem is to add the flags as described in the pyenv installation FAQs: that solution eventually led me to install the python version I wanted:
LDFLAGS="-L/usr/lib/openssl-1.0" \
CFLAGS="-I/usr/include/openssl-1.0" \
pyenv install -v 3.4.3
To avoid to go on the FAQs page everytime you want to renew the python installation environment, you can add an alias in ~/.bashrc or whatever is you shell as follows:
echo alias pyenv='LDFLAGS="-L/usr/lib/openssl-1.0" \
CFLAGS="-I/usr/include/openssl-1.0" \
pyenv' >> ~/.bashrc
In this way you can install python properly with a clean pyenv syntax, and manage it via its plugins in the same way (since the syntax is pyenv [COMMAND] [OTHERSTUFF]).

No, there is no better way to do this. The python symlink is part of the Python 3 package.
I guess changing this link won't break anything for now but it might be possible that some packages will depend on it in the future.