[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.
Basically if you are writing a library, you should use the most specific version(s) of python you can use. Otherwise as an end user, you should feel free to rename this for your own personal use (though your OS or distribution may not make that easy).
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. 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.)
