I had the same issue, but on Windows 7, and a restart didn’t fix it.
I already had gVim 7.3 installed. At the time of writing the current Python version was 3.3, so I installed that. But :has (“python”) and :has (“python3”) still returned 0.
After much trial and error, I determined that:
- If gVim is 32-bit, and it usually is even on 64-bit Windows (you can confirm using the :version command), then you need the 32-bit python installation as well
- No restart of Windows 7 is required
- The version of python needs to match the version that gVim is compiled for as it looks for a specific DLL name. You can work this out from the :version command in gVim, which gives something like:
Compilation: cl -c /W3 /nologo -I. -Iproto -DHAVE_PATHDEF -DWIN32
-DFEAT_CSCOPE -DFEAT_ NETBEANS_INTG -DFEAT_XPM_W32 -DWINVER=0x0400 -D_WIN32_WINNT=0x0400 /Fo.\ObjGOLYHTR/ / Ox /GL -DNDEBUG /Zl /MT -DFEAT_OLE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DFEAT_GUI_W32 -DDYNAMI C_ICONV -DDYNAMIC_GETTEXT -DFEAT_TCL -DDYNAMIC_TCL
-DDYNAMIC_TCL_DLL=\”tcl83.dll\” -DDYNAM IC_TCL_VER=\”8.3\” -DFEAT_PYTHON -DDYNAMIC_PYTHON -DDYNAMIC_PYTHON_DLL=\”python27.dll\” -D FEAT_PYTHON3 -DDYNAMIC_PYTHON3 -DDYNAMIC_PYTHON3_DLL=\”python31.dll\” -DFEAT_PERL -DDYNAMI C_PERL -DDYNAMIC_PERL_DLL=\”perl512.dll\” -DFEAT_RUBY -DDYNAMIC_RUBY -DDYNAMIC_RUBY_VER=19 1 -DDYNAMIC_RUBY_DLL=\”msvcrt-ruby191.dll\” -DFEAT_BIG /Fd.\ObjGOLYHTR/ /Zi
So the above told me that I don’t actually want python 3.3, I need 3.1 (or 2.7). After installing python 3.1, :has (“python”) still returns 0, but :has (“python3”) now returns 1. That should mean that python based scripts will now work!
I imagine future versions of gVim may be compiled against other versions of python, but using this method should let you work out which version is required.