Felix Krull runs a PPA offering basically any version of Python (seriously, there is 2.3.7 build for vivid...) for many Ubuntu releases at https://launchpad.net/~deadsnakes/+archive/ubuntu/ppa.

Do the usual:

sudo add-apt-repository ppa:deadsnakes/ppa
sudo apt-get update
sudo apt-get install python3.5

It will not overwrite your existing python3.4 which is still symlinked as python3.

Instead, to run python3.5, run the command python3.5 (or python3.X for any other version of python).

DON'T change the symlink! There are apparently many system functions that don't work properly with python3.5.

I tried this and afterwards couldn't open a terminal, software updater,...

cd /usr/bin
sudo rm python3

The upgrade to Wily will adapt the meta-package python3 to point to python3.5. I don't expect any breakage, but at this point the foreign repository is not needed anymore. So to be really safe, you can purge the PPA before doing the upgrade.

Python has got its own package managing facilities, in parallel to the one sets by the Linux distributions (including Ubuntu). The repository is the Pypi - Python Package Index, and packages are installed with pip or the easy_install script, which is part of Python's setuptools package.

As a rule of thumb, you should not use both the packages installed via pip/setuptools, and packages available to your distro (via apt-get, yum, urpmi, etc...) as they might conflict.

So, one of the less error prone way to deal with it is to have separate Python installs in your system - leave the python that came with the system for system scripts and such - on this python, make use of packages installed by your package manager only. And install other versions of Python (or even the same), to be run with "virtualenv"s - on these other install you install things with pip/setuptools only.

(And even if one opt to live boldly and not use virtualenvs, installing another python version on the same prefix (/usr, and even /usr/local) than your system's Python is a source to confusing errors and conflicts).

Note that the Debian - and Ubuntu - systems devised a way to run parallel official Python's in /usr, and to have apt-get to install Python packages to both Python versions at once. This mostly works, but they mess with Python's default directory hierarchy, and some applications fail to use Python in this way. (It is also a mess to find the module files themselves in a Debian or Ubuntu). So the above method apply as a recommendation even if your system do have more than one version of Python available on apt-get.

In short, once you have compiled your desired version of Python, do this:

1. use your system's package manager to install "python-setuptools" and "python-virtualenv" (not sure if these are the actual package names).
2. Use virtualenv to create an environment from which you will use your different Python version
3. Activate your virtualenv, and install Python packages using pip on it.

Virtualenv does feature a "--help" switch to help you, but you basically do:

$ virtualenv -p <path-to-python-interpreter>  <environment-dir>
$ source <environment-dir>/bin/activate

And there you are - all things using Python will "see" the interpreter in the virtualenv, due to environment variables set.

I will appreciate if someone could explain the differences (if any) between:

Highest level: you never should use pip install to install to system (--system, or on Linux distros where --user isn't the default, omitting --user) when things might conflict with your system whereas apt install is pretty safe.

Explanation:

apt is the package installation tool of your Linux distro. A Linux distribution these days is mostly the effort to offer a way to install packages in a way that works with each other without breaking – for example, if you're trying to install a library that libreoffice uses, but in a version incompatible with your libreoffice, your linux distro tool will tell you that sadly, to fulfill your command, it will have to uninstall libreoffice, because it wouldn't work with that version you're requesting.

The fact that you very rarely see that happen is an indication of how well modern Linux distros are doing here: typically, most of software that you can install using apt works well together.

pip, on the other hand, has no notion of what other software you have on your machine, which you might need. You tell pip to install something in a version that breaks your ability to even boot your system – it will go ahead and do that.

pip is python-specific. It assumes that all there is on that machine that has something to do with Python is kind of "fair game" and can be dealt with arbitrarily. Frankly, that is almost never the case – for example, on Fedora (another Linux distro that you're not using), you can easily break the installation tool dnf (Fedora's apt, if you will) with pip.

So, why does pip still exist? Well, there are situation where it's OK for pip to assume every bit of python it sees is under its control: Python brings a mechanism called virtual environments. In these, no python modules are per se installed, and they don't conflict with other software on your machine – simply because other software isn't aware of the environment.

Using that is quite straightforward. You can set up such an environment using

python3 -m venv ~/bertsexperiment

That sets up a folder ~/bertsexperiment for Python stuff to be installed into. You can then, from anywhere you like, "activate" that environment (what that really does is just change a few environment variables) – but that only affects the current process and things started from it. Try it:

source ~/bertsexperiment/bin/activate

will set up this shell in a way that all future python tooling will work with that folder as "prefix".

For example, if you wanted to have an updated setuptools in that shell, you could, after sourceing the activaton script as shown above, run pip3 install --upgrade setuptools, and they would be installed into the virtualenv.

In short:

• if in doubt, use apt, because it's your distro's job to keep your software stack working together
• Never use pip unless you intend to install something into a folder only used for your current project and not by anything else on your system.
  Hence, the only realistic time you would want to use it is when you're using a Python virtualenv.

The set of currently supported python versions can be found in /usr/share/python/debian_defaults. Check whenever python-2.7 is listed there as supported.

There is a so-called python-support system in Debian. When python-support-aware package (i.e., when maintainer used python-support stuff while packaging) says that it supports specific range of Python versions, dpkg calls hooks for updates to installed runtimes as a part of postinst process. There's also alternative python-central system, which does the same thing.