From the comment:

sudo update-alternatives --config python

Will show you an error:

update-alternatives: error: no alternatives for python3 

You need to update your update-alternatives , then you will be able to set your default python version.

sudo update-alternatives --install /usr/bin/python python /usr/bin/python3.4 1
sudo update-alternatives --install /usr/bin/python python /usr/bin/python3.6 2

Then run :

sudo update-alternatives --config python

Set python3.6 as default.

Or use the following command to set python3.6 as default:

sudo update-alternatives  --set python /usr/bin/python3.6

You can always use sudo update-alternatives --config python3 and then select your python3 version. That should solve your issue without needing to do weird configs.

The correct way is sudo apt install python-is-python3 - it effectively does a symlink, but it also keeps pace with future updates; so if your ubuntu distribution moves to say Python 3.9, the manual symlink will no longer work, but the package makes sure it is still valid.

[updated for 2021]

(Regardless if you are on Mac, Linux, or Windows:)

If you are confused about how to start the latest version of python, on most platforms it is the case that python3 leaves your python2 installation intact (due to the above compatibility reasons); thus you can start python3 with the python3 command.

Historically...

The naming convention is that generally, most scripts will call python2 or python3 explicitly. This happened due to a need for backwards compatibility.

Even though technically python doesn't even guarantee backwards compatibility between minor versions, Python3 really breaks backwards compatibility. At the time, programs invoking 'python' were expecting python2 (which was the main version at the time). Extremely old systems may have programs and scripts which expect python=python2, and changing this would break those programs and scripts.

At the time this answer was written, OP should not have changed this due to maintaining compatibility for old scripts.

Circa year 2021...

Nowadays, many years after the python2->python3 transition, most software explicitly refers to python2 or python3 (at least on Linux). For example, they might call #!/usr/bin/env python2 or #!/usr/bin/env python3. This has for example (python-is-python3-package) freed up the python command to be settable to a user default, but it really depends on the operating system.

The prescription for how distributions should handle the python command was written up in 2011 as PEP 394 -- The "python" Command on Unix-Like Systems. It was last updated in June 2019.

Regardless of whether you are writing a library or your program, you should specify the version of python (2 or 3, or finer-grained under specific circumstances) you can use in the shebang line, or since you're on OS X, in your IDE with which you are developing your app, so it doesn't mess up the rest of the system (this is what python venvs are for... download and search how to up set up a python3 venv on Mac if you're on a really really old version of OS X).

Shell alias:

You could, however, make a custom alias in your shell. The way you do so depends on the shell, but perhaps you could do alias py=python3, and put it in your shell startup file (.bashrc, .zshrc, etc). This will only work on your local computer (as it should), and is somewhat unnecessary compared to just typing it out (unless you invoke the command constantly).

Confused users should not try to create aliases or virtual environments or similar that make python execute python3; this is poor form.This is acceptable nowadays, but PEP 394 suggests encouraging users to use a virtualenv instead.

Different 3.* versions, or 2.* versions:

In the extremely unlikely case that if someone comes to this question with two python3 versions e.g. 3.1 vs 3.2, and you are confused that you have somehow installed two versions of python, this is possibly because you have done manual and/or manual installations. You can use your OS's standard package/program install/uninstall/management facilities to help track things down, and perhaps (unless you are doing dev work that surprisingly is impacted by the few backwards-incompatible changes between minor versions) delete the old version (or do make uninstall if you did a manual installation). If you require two versions, then reconfigure your $PATH variable so the 'default' version you want is in front; or if you are using most Linux distros, the command you are looking for is sudo update-alternatives. Make sure any programs you run which need access to the older versions may be properly invoked by their calling environment or shell (by setting up the var PATH in that environment).

A bit about $PATH

sidenote: To elaborate a bit on PATH: the usual ways that programs are selected is via the PATH (echo $PATH on Linux and Mac) environment variable. You can always run a program with the full path e.g. /usr/bin/🔳 some args, or cd /usr/bin then ./🔳 some args (replace blank with the 'echo' program I mentioned above for example), but otherwise typing 🔳 some args has no meaning without PATH env variable which declares the directories we implicitly may search-then-execute files from (if /usr/bin was not in PATH, then it would say 🔳: command not found). The first matching command in the first directory is the one which is executed (the which command on Linux and Mac will tell you which sub-path this is). Usually it is (e.g. on Linux, but similar on Mac) something like /usr/bin/python which is a symlink to other symlinks to the final version somewhere, e.g.:

% echo $PATH
/usr/sbin:/usr/local/bin:/usr/sbin:usr/local/bin:/usr/bin:/bin

% which python
/usr/bin/python
% which python2
/usr/bin/python2
% ls -l /usr/bin/python
lrwxrwxrwx 1 root root 7 Mar  4  2019 /usr/bin/python -> python2*
% ls -l /usr/bin/python2  
lrwxrwxrwx 1 root root 9 Mar  4  2019 /usr/bin/python2 -> python2.7*
% ls -l /usr/bin/python2.7
-rwxr-xr-x 1 root root 3689352 Oct 10  2019 /usr/bin/python2.7*

% which python3         
/usr/bin/python3
% ls -l /usr/bin/python3
lrwxrwxrwx 1 root root 9 Mar 26  2019 /usr/bin/python3 -> python3.7*
% ls -l /usr/bin/python3.7
-rwxr-xr-x 2 root root 4877888 Apr  2  2019 /usr/bin/python3.7*

% ls -l /usr/bin/python*
lrwxrwxrwx 1 root root       7 Mar  4  2019 /usr/bin/python -> python2*
lrwxrwxrwx 1 root root       9 Mar  4  2019 /usr/bin/python2 -> python2.7*
-rwxr-xr-x 1 root root 3689352 Oct 10  2019 /usr/bin/python2.7*
lrwxrwxrwx 1 root root       9 Mar 26  2019 /usr/bin/python3 -> python3.7*
-rwxr-xr-x 2 root root 4877888 Apr  2  2019 /usr/bin/python3.7*
lrwxrwxrwx 1 root root      33 Apr  2  2019 /usr/bin/python3.7-config -> x86_64-linux-gnu-python3.7-config*
-rwxr-xr-x 2 root root 4877888 Apr  2  2019 /usr/bin/python3.7m*
lrwxrwxrwx 1 root root      34 Apr  2  2019 /usr/bin/python3.7m-config -> x86_64-linux-gnu-python3.7m-config*
lrwxrwxrwx 1 root root      16 Mar 26  2019 /usr/bin/python3-config -> python3.7-config*
lrwxrwxrwx 1 root root      10 Mar 26  2019 /usr/bin/python3m -> python3.7m*
lrwxrwxrwx 1 root root      17 Mar 26  2019 /usr/bin/python3m-config -> python3.7m-config*

sidenote2: (In the rarer case a python program invokes a sub-program with the subprocess module, to specify which program to run, one can modify the paths of subprocesses with sys.path from the sys module or the PYTHONPATH environment variable set on the parent, or specifying the full path... but since the path is inherited by child processes this is not remotely likely an issue.)