The attached patch adds a CustomBuildStep to python.vcxproj which creates a 'python.bat' script in the root of the source tree for quicker and easier invocation for testing purposes, and to make the Windows Python developer experience a little closer to the UNIX experience.  Sample output:

"""
C:\path\to\cpython>type python.bat
@rem This script invokes the most recently built Python with all arguments
@rem passed through to the interpreter.  This file is generated by the
@rem build process and any changes *will* be thrown away by the next
@rem rebuild.
@rem This is only meant as a convenience for developing CPython
@rem and using it outside of that context is ill-advised.
@echo Running Debug^|Win32 interpreter...
@"C:\path\to\cpython\PCbuild\python_d.exe" %*

C:\path\to\cpython>python -c "import sys;print(sys.version)"
Running Debug|Win32 interpreter...
3.4.0b1 (default:6864abd8e83a+, Dec 12 2013, 08:35:32) [MSC v.1600 32 bit (Intel
)]
"""

As the commentary (which can likely be improved) states, the script is re-created by every rebuild, so it always points to the most recently built interpreter.  Also, being a CustomBuildStep, it is cleaned up automatically by the Clean build target.

I'm not sure whether echoing the interpreter configuration is the best idea, but I personally prefer that over echoing the full command which has the potential to be very long.  I think that the Configuration/Platform should be displayed somehow to reduce confusion since there could be up to 8 different interpreters living together in PCbuild (not to mention PC/VS10.0, when it exists someday) and python.bat will only point to one of them.

Note that the x64 changes are done by hand and untested; I don't have the ability to do so just yet.