Without more knowledge of how you ended up where you are, there are no guarantees for "safe".
If you used pip or similar to install Python software then it will have installed for whichever Python version your system is preferring, which means the one in /usr/local/bin.
The system-supplied version in /usr/bin should probably not be touched or removed. If you installed components using apt-get install (or its cousins, aptitude, Synaptic, etc) then they will have been installed for the system Python.
Fundamentally, Apt and pip are competing to manage your Python code, and mixing them will end up in a situation where there is no simple way to reconcile. If you only used one or the other, then it should be easy to manage the code you already have installed, and modify it if you need to.
I second the suggestion to use virtualenv, perhaps as a first step towards a single install; but I expect you will find that you can actually live comfortably with multiple Python versions then. With virtualenv, you are not dependent on what is installed system-wide in the first place.
Typically, you would set up (at least) one virtual environment for each Python project you work on, and populate it with only the libraries which that particular project needs. So for example, to set up a virtualenv for using the system Python and use the libraries you specified, you'd do something like
vnix$ virtualenv -p /usr/bin/python myproject
vnix$ ./myproject/bin/activate
(myproject) vnix$ pip install numpy matplotlib # Tkinter is part of standard Python install
(myproject) vnix$ emacs myproject.py & # hack away
The virtual environment contains a copy of your bare Python install (though that is hardly "bare", with all the batteries included) and anything you pip install while the virtualenv is active will only be installed inside the virtual environment. That way, you can nicely isolate dependencies, and work on software even with conflicting requirements simply by switching from one virtual environment to another.
Thus, if you like, you can create a second virtual environment with the locally installed Python and install Tkinter inside that virtual environment simply by running pip install when the environment is activated.
(myproject) vnix$ deactivate
vnix$ cd ..
vnix$ virtualenv myproject-local
vnix$ . ./myproject-local/bin/activate
(myproject-local) vnix$ pip install numpy matplotlib Tkinter
(Not sure how you could end up without Tkinter in your Python install so also not sure how you would install it there. pip install Tkinter does not seem to work at least where I am, so additional hacks are probably necessary. Install tkinter for Python seems relevant. Rebuilding and reinstalling Python in /usr/local, this time with Tkinter, seems like a plausible, albeit somewhat unattractive solution.)
As an aside, you probably want your project in version control; there is no need for the virtual environments to end up there, and in fact, virtualenv works nicely completely outside of your source tree if you prefer that. As an extreme example, you could create your virtual environments in /tmp and have them removed at reboot; the location of the virtualenv tree on disk is unimportant. (Maybe you want requirements.txt in version control so that you can easily recreate the virtual environment, though. pip install -r requirements.txt will install all the required packages listed in the file in one go.)
