We Keep Coding

Install GVIM on windows with Python3 support?

How do I install GVIM for Windows with Python3 support? I have installed VIM 7.4 which says in it's version file (run :version command) "+python3/dyn" and "-DDYNAMIC_PYTHON3_DLL=\"python32.dll\". So it looks like it's ready to support Python 3. When I run
:echo has("python3")
it returns zero. And if I test with
:py3 print("hello")
it says it cannot load python32.dll.

Here is an approach that I used to get VIM 7.x to work with Python 3.x.
Install a VIM of your preference. Suggestion: get the latest version from VIM.org, though this site seems to have only 32-bit versions. If you want 64-bit (my preference) get a pre-built at https://bintray.com/veegee/generic/vim_x64 or choose your own pre-built elsewhere, or build your own.
Type the command :py3 print("hello")
It probably will not find the python dll, in which case it gives an error message like cannot load pythonXX.dll where XX is a two-digit number. In my case, VIM was looking for python35.dll, which comes from Python 3.5.1 (and probably any Python 3.5.x). The number will vary depending on the version of VIM you use.
Go find a matching Python distribution. Matching means that both VIM and Python must be either 32-bit or 64-bit, and the DLL that VIM wants (in step 3) is present. So for example, it appears that Python 3.5.x provides python35.dll. Install it.
I don't recall having to do anything special to get VIM to find the python DLL, other than ensuring that the directory it is in should be in the path, and I think it already was. If not, add the directory with the DLL to your path.
Retry step 2. It should work now.
If in the future you upgrade VIM or Python, you may need to upgrade the other one at the same time, to ensure that the test in step 2 still works.

The problem that makes this question so hard is that specific solutions very quickly become obsolete. The day the solution is posted the version of vim or python is updated or links change. The steps provided by #mark-colon are fantastic but oriented for vim-7.
Generic instructions:
vim and python need to be in sync on many different levels:
Both need to be 32bit or 64bit
Vim needs to find a specific python dll version. It depends on who compiled your version of gvim. For example, gvim-8.1.x may use python3.6 or python3.7 and the exact version is required! Sometimes you can use: gvim --version to see what specific dll is being searched by vim at launch, otherwise you need to find out from where you downloaded gvim. This is the version of python that you must search the internet and install on your system. (Alternatively, if the version of python is more important to you than the version of vim, you can try to find a version of vim that was compiled for python but this will be harder to find.)
Make sure the directory that holds the python dll needs to be on the %PATH% environment variable. (Note: some just copying the python dll to the $VIM folder to get things working only works in the short term. You don't have all the necessary python libraries that are often assumed to be available.)
Finally, verify with ex command :python2 print("hello") or :python3 print("hello") depending on what version of python you wanted.
Specific links (if you must):
Note: these will all soon be out of date, but the following are some links to various compiled versions of gvim and python that could work together:
For gvim-8.1.x & python-3.7.x or python-2.7.x as of 2018-08:
https://tuxproject.de/projects/vim/
http://winpython.github.io/ or https://www.python.org/downloads
For gvim-8.1.x & python-3.6.x or python-2.7.x as of 2018-08:
https://github.com/vim/vim-win32-installer/releases
https://www.python.org/downloads
For gvim-7.4.x & python-3.5.x or python-2.7.x as of 2018-08:
https://bintray.com/veegee/generic/vim_x64
https://www.python.org/downloads

Unfortunately this took me a day to figure out. Here's the simplest way to remedy this problem, if you are looking to have Python3 support with GVIM 7.3+ on Windows.
I am running 64-bit Windows 8, but, make sure you grab a 32-bit version of Python. You will most likely have a 32-bit version of GVIM by default, and those 2 need to match. Specifically, grab a 3.2.x version of Python3 because that's what VIM is looking for as far as a DLL is concerned (python32.dll). Don't bother with the latest version of Python 3, 3.4.0 at the time of writing; and if you do need that, then I'm not sure how to help.
Once you have Python 3.2.x installed, make sure you do this last tricky part:
The python32.dll is not placed in system32 folder, it is actually in the C:\Windows\SysWOW64 folder. You need to add "C:\Windows\SysWOW64" to your PATH environment variable.
Now re-try your python3 tests in GVIM and it should be successful.

I use Haroogan's compiled version, it's great and has a 64-bit version for windows.
EDIT:
veegee's version seems to be a good alternative. Thanks to Markus Meskanen in the comment.

I have tested that you should use the same architecture for both vim and python.
see https://vi.stackexchange.com/questions/11004/how-to-get-python-support
If you just need python feature in vim, download python36.dll and put in $VIM and verify by :echo has('python3')

I have 2 versions of python installed, but cmake is using older version. How do I force cmake to use the newer version?

I have 2 versions of python installed, but cmake is using older version. How do I force cmake to use the newer version?

You may try either of these depending on what you need:
For CMake >= 3.12
According to the changelog:
New "FindPython3" and "FindPython2" modules, as well as a new
"FindPython" module, have been added to provide a new way to locate
python environments.
find_package(Python COMPONENTS Interpreter Development)
Docs:
This module looks preferably for version 3 of Python. If not found,
version 2 is searched. To manage concurrent versions 3 and 2 of
Python, use FindPython3 and FindPython2 modules rather than this one.
For CMake < 3.12
Docs:
find_package(PythonInterp 2.7 REQUIRED)
find_package(PythonLibs 2.7 REQUIRED)

Try to add -DPYTHON_EXECUTABLE:FILEPATH=/path/to/python2.7
It might be a path problem?
Also could specify the path to your python library,use your version that you want:
cmake -DPYTHON_LIBRARIES=/Library/Frameworks/Python.framework/Versions/2.7/lib/libpython2.7.dylib .

I had a similar problem, and resolved it using Paul's answer as a hint. I needed to use python2.7 to compile an older library, but cmake keeps picking up my python3.2 libraries (and executable).
First, I ran cmake with default options, then edited the CMakeCache.txt file which it generated. I did it this way primarily because I didn't know the proper -D... incantations to cause cmake to get the python library and include paths, etc right in the first place.
In my CmakeCache.txt, I found lines like this
Path to a program
PYTHON_EXECUTABLE:FILEPATH=/usr/bin/python
Path to a directory
PYTHON_INCLUDE_DIR:PATH=/usr/include/python3.2
Path to a library
PYTHON_LIBRARY:FILEPATH=/usr/lib/libpython3.2.so
And replaced every occurrence of python3.2 with python2.7. I also had to rename the PYTHON_EXECUTABLE to use python2.7, since python is a symlink to python3.2 on my system.
Then I reran cmake. Because it prefers its cached values to actually looking for the libraries, this should work in all cases. At least, it did in mine.

I use anaconda(python 2.7.8) as well as python 2.7.6.
I tried -DPYTHON_EXECUTABLE:FILEPATH=$ANACONDA_HOME/bin, but version 1.4 found (weird:).
My solution is changing it to PYTHON_EXECUTABLE:
cmake -D CMAKE_BUILD_TYPE=RELEASE -D CMAKE_INSTALL_PREFIX=/usr/local -DBUILD_TIFF=ON \
-DPYTHON_LIBRARY=$ANACONDA_HOME/lib/libpython2.7.so \
-DPYTHON_INCLUDE_DIR=$ANACONDA_HOME/include/python2.7/ \
-DPYTHON_EXECUTABLE=$ANACONDA_HOME/bin/python

My use case was a rather large project in which C++ classes were made available to Python scripts via Boost.Python. After having fought the various quirks of CMake's Python interpreter and library detection, I finally gave up and rolled my own. My approach is based on a slightly after-edited version of the python-config script that is sometimes (but not always!) put into a newly created virtual environment (see this SO post on pyvenv for these issues, but I digress). This script is invoked by a small CMake snippet pyconfig.cmake. Both are freely available from the GitHub repo cmake-python-config.
Warning: The scripts assume that you have a Python 3 interpreter in your PATH. Detection of Python 2 is not attempted. The scripts do not attempt to find all installed versions of Python3 either.

Building 64bit libpython27.a using cygwin, dlltool

I'm trying to build a python extension DLL on a 64bit Win7 machine using cygwin (as cygwin only run as 32bit process, this is actually cross-compiling).
I created libpython27.a myself from python27.dll using dlltool (as explained, for example, here), but the build fail during the linker phase saying
skipping incompatible c:\Python27\libs/libpython27.a when searching for -lpython27
This is exactly the error reported here (where the guy ended up moving to MSVC compiler...).
More info:
- Active Python 2.7.2, win64, x64
- latest version of cygwin, using the /usr/bin/x86_64-w64-mingw32-g++.exe compiler
Does anyone know if this is supported?
Is there way to use dlltool which I miss here?
(I did found here the guidance to use
dlltool --as-flags=--64 -m i386:x86-64 -k -l libpython27.a -d python.def
but when doing so I got "invalid bfd target" error from dlltool)
Thanks!
Update: I believe it can be done because Enthought python contains such a file. I would like to create one for the more common distributions which don't contain it.

The problem is that you are using the 32 bit dlltool. Probably in C:\MinGW\bin instead of C:\MinGW64\bin. You can change your path, or run the 64 bit tool specifically as such:
C:\MinGW64\bin\dlltool -v --dllname python27.dll --def python27.def --output-lib libpython27.a

I'm not sure how helpful you find this, but at the bottom of the page you linked to there's a link to here - Where it says:
Do not use MinGW-w64. As you will notice, the MinGW import library for
Python (e.g. libpython27.a) is omitted from the AMD64 version of
Python. This is deliberate. Do not try to make one using dlltool.
There is no official MinGW-w64 release yet, it is still in "beta" and
considered unstable, although you can get a 64-bit build from e.g.
TDM-GCC. There have also been issues with the mingw runtime
conflicting with the MSVC runtime; this can happen from places you
don't expect, such as inside runtime libraries for g++ or gfortran. To
stay on the safe side, avoid MinGW-w64 for now.

Finding the correct Python framework with cmake

I am using the macports version of python on a Snow Leopard computer, and using cmake to build a cross-platform extension to it. I search for the python interpreter and libraries on the system using the following commands in CMakeLists.txt
include(FindPythonInterp)
include(FindPythonLibs )
However, while cmake identified the correct interpreter in /opt/local/bin, it tries to link against the wrong framework - namely the system Python framework.
-- Found PythonInterp: /opt/local/bin/python2.6
-- Found PythonLibs: -framework Python
And this causes the following runtime error
Fatal Python error: Interpreter not initialized (version mismatch?)
As soon as I replace -framework Python with /opt/local/Library/Frameworks/Python.framework/Python things seem to work as expected.
How can I make cmake link against the correct Python framework found in
/opt/local/Library/Frameworks/Python.framework/Python
rather than the system one in
/System/Library/Frameworks/Python.framework/Python
?

Adding the following in ~/.bash_profile
export DYLD_FRAMEWORK_PATH=/opt/local/Library/Frameworks
fixes the problem at least temporarily. Apparently, this inconsistency between the python interpreter and the python framework used by cmake is a bug that should be hopefully fixed in the new version.

I am not intimately familiar with CMake, but with the Apple version of gcc/ld, you can pass the -F flag to specify a new framework search path. For example, -F/opt/local/Library/Frameworks will search in MacPorts' frameworks directory. If you can specify such a flag using CMake, it may solve your problem.

Python on AIX: What are my options?

I need to make some Python applications for a work project. The target platform is AIX 5.3.
My question is: What version of Python should I be using?
My requirements are:
The Python version must be easy to install on the target machines. Others will do that according to instructions that I write, so no compiling from source or anything like that.
The Python version must have ncurses or curses support (I'm making a form handler).
I've found two different precompiled versions of Python for AIX, but one (2.1.something) didn't include the curses module, and the other (2.3.4, RPM format) had prerequisites that I failed to fulfill).
Any help would be greatly appreciated.

Use the AS Package of Python 2.6.3.7 from Activestate. They have a binary package for AIX on their download site.
If you don't have an AIX machine to test it on, the install works the same way on Solaris or Linux, so you could write your documentation based on that. Basically, you ungzip the tarball file, use tar to unpack the archive, change directory to the unpacked folder, run a shell script to install it, tell the shell script what directory to place it in, and wait.
Normally this would be used to install into a user directory, without superuser permissions, but you could install it anywhere that you like. You might also need to edit the system profile in order to make sure that all users can find the Python binary.
I suggest the latest Python 2.6, because it has a lot of bugfixes, and there is now a critical mass of 3rd party libraries ported to it. Also, the standard library includes a lot of useful stuff that you used to have to collect separately. Curses is in the standard library of Python 2.6.
Make sure to avoid Python 3.1 since it has not yet matured enough and provides few benefits for most business applications development.

I'd compile it from source myself and tell them where to download it from in the instructions

We've used ActiveState's Python as well as Pware's compiled version. Both have worked well. For AS, we've used 2.5 and 2.6. For Pware, just 2.6. Both 2.5 and 2.6 from AS support curses on our machine.
I've compiled from source but usually wind up having trouble with with ctypes or SSL. Currently I have the Frankenstein option going of AS Python2.6 installed but I pulled out a couple of *.so files from Pware's. I'm using GCC since we've never ponied up for a compiler but depending on what you need from Python, it's definitely doable if I can do it.
I will mention that AS Python claims to be 100% compatible with standard Python and it has been for everything we've done so far (mostly web applications).