The #! line is not used and would not normally be placed into a WSGI script file as used by mod_wsgi.
To determine which version/installation of Python is used, there are two parts to it.
The first as pointed out by someone else is to work out which Python library mod_wsgi.so is linked to. On most UNIX systems this is done using the 'ldd' command.
Run this on the actual mod_wsgi.so installed into the Apache modules directory which is being used. This will tell you for certain which version of mod_wsgi was compiled against.
If you do not see a reference to a libpythonX.Y.so file then your mod_wsgi.so was linked statically against Python library. Although this will work, so long as mod_python not also loaded into same Apache, it is a very bad idea to rely on it as use of static linking of Python library results in unnecessary bloating of your Apache processes due to runtime code relocation that has to be done when loading mod_wsgi.so with statically linked Python library.
Note that the value of 'sys.executable' when running under mod_wsgi has no meaning and cannot be used as a means of determining which Python version was used. This is because the command line Python is not used. Instead, the executable which is being run is actually Apache and sys.executable most likely will reflect that. It is only after Apache is run and the mod_wsgi.so loaded that Python is then initialised using embedded Python APIs. Similarly, running 'which python' will not help in determining exactly which installation of Python is being used.
The second part is working out what installation of Python was actually used at runtime. To do this you should use a WSGI hello world program and modify it to dump out the value of 'sys.prefix'. This tells you the root directory under which the Python installation is located. Based on what version of the Python shared library was used, you will then know which actual 'lib/pythonX.Y' directory under that root directory is being used. The version is important as there could well be multiple versions installed under that root directory.
Note that what you get for 'sys.prefix' may actually be different to the root directory as you thought it may be based on libpythonX.Y.so dependency of mod_wsgi.so file. This is because of the way that Python when initialised tries to find its 'lib' directory.
For example, if you had Python 2.6 installed under '/usr/local' and another one installed under '/usr', but you compiled mod_wsgi against that under '/usr/local', you may still find that 'sys.prefix' resolved to '/usr'. This is because by default in embedded systems Python looks at value of 'PATH' environment variable to get a search path to find a 'python' executable as base point for calculating the root directory, even though that 'python' executable was not used to start the process.
Under Apache, because it is usually started as 'root', it would not necessarily have '/usr/local/bin' in your 'PATH' and so would likely find '/usr/bin/python' instead and thus use '/usr' for 'sys.prefix'.
In this later sort of scenario where it finds a different root directory to what you want to use, one can use the WSGIPythonHome directive in Apache configuration to override what 'sys.prefix' is automatically calculated.
Note that you CANNOT use WSGIPythonHome to refer to a different version of Python, it must refer to a root directory containing a Python installation of the same major/minor version. If you need to use a different version of Python, you must recompile and reinstall mod_wsgi so it is compiled against the different version. The actual version/installation of Python to be used when compiling can be specified using the '--with-python' option to the mod_wsgi configure script when it is being built.
There are other ways besides using WSGIPythonHome directive to override which Python installation is used, but recommended you stick with WSGIPythonHome.