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')
Related
Using Ubuntu 16.04.
I was doing development in Python2.7, although recently moved to Python3.5, both of which come by default. The problem is, I find all the python libraries have to be reinstalled or downloaded for the next Python3. Also, the behaviour of Python seems weird because to execute the same script in python3, I have to enter in terminal
python3 script.py
which is different from other applications where I do not have to give the version number. Anyway, the questions I am trying to find answers are
To what extent are the libraries, packages (such as pip etc.) shared between 2.7 and 3.5? Or do I need double installations (and double the space) for everything now? A bit space limited in my old laptop.
Most of the installation instructions and commands I find online do not specify whether they are for 2 or 3. Given that I have two versions, how do I control/make sure they go to 3.5?
Is it advisable and possible to completely remove everything related to 2.7? Can I keep working with 3.5?
The first thing you need to know is that all official libraries and python tools for python3 got the "3" character to separate them from the previous versions. So, you need to use pip3, and not pip, python3, not python, and the packages are called python-pygame, not python-pygame.
So, to answer to you in order:
Yes, the you have to double the space needed if you decide to use both python2 and python3
Usually, if in the tool name there is 3, it is for python3, and if not it's for python2
Python2 and python3 are completly indipendent (different path, indipendent versions, etc.) so having python 2.7 installed doesn't affect python3 BUT since python 3 is the next version of python 2, it makes it obsolete (in my opinion) so if you don't have enough space for both, keeping python2 is absolutely not needed nor useful
If you want to control your python execution then you have various method or techniques:
For downloading packages according to version
You can use pip{version-name} to download the libraries. Like if you want to download library of python 2.7 then write
pip2.7 install package-name
for python 3.5 then use
pip3.5 install package-name
For execution of program:
If you want to execute the program accoridng to you choice of version then just use
python{version-name} script.py
eg:
python2 script.py
python3 script.py
or you just write down the path of your python version on the top of script. Please refer this for more details:
Why do people write #!/usr/bin/env python on the first line of a Python script?
I'm trying to load a python extension to WinDBG, using PyKd.
.load pykd succeeds.
When I'm running !py, I get this:
failed to find python interpreter
Things I've tried:
Different versions of python
Using PyKd's dll and pyd files
.reload /f
Different symbol paths
Debugging WinDBG and PyKd, also going through the source, no success
Yes, my environment is set correctly with the Python path.
Couldn't find any mention of that problem in the web.
It had always ran smoothly on different systems and configurations I had, but on my new system I get this weird message.
Details:
Windows 10 Home, version 1607, x64
WinDBG x86, build 10.0.15063.0
Python 2.7.13, but I tried many other versions as well.
Symbols path: cache*c:\symbols;srv*https://msdl.microsoft.com/download/symbols
Dell XPS 15
guy
I installed the latest pykd too, and occur the same problem.
Then I found that I hadn't installed python 2.7 at this virtualbox.
Installing python 2.7 will work.
You have installed it.I suggest you check whether python installation path is in "path" environment variable
if you don't have this register path:HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\xx\PythonPath, then you should install python-2.7(x64) with Path enabled.
I had this issue when having multiple python installations on the same machine. Managed to solve it by manually creating required registry key, as I did not want to reinstall any python versions, nor change the global path/pythonpath variables.
Note that you will need x64 python for windbgx64 and x86 python for windbgx86
Let's say you want to use python 3.7x86 installed at c:\python37_x86, and python 3.6x64 installed at c:\python36_x64
Create keys leading to HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Python\PythonCore\3.7-32\InstallPath there, and set the (Default) to c:\python37_x86\ (the trailing backslash is important!)
Similarly, create keys leading to HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\3.6\InstallPath there, and set the (Default) to c:\python36_x64\
Unfortunately the PYTHONPATH environment variable is still being used, and must match the referenced python version(otherwise you will encounter Fatal Python error: unable to load the file system codec . NOTE: this may only be important if one of the versions is 2.x and the other 3.x. Try making it work without this step
To circumvent the last issue I created .bat files to modify the environment and launch windbg with the correct environment.
For example for launching 32 bit windbg:
set PYTHONPATH=C:\python37_x86\Lib;[...Rest of the PYTHONPATH for this python version...]
start windbgx -debugArch x86 -c ".load c:\dev\tools\pykd\x86\pykd.dll"
WinDBG x86, build 10.0.15063.0
Python 2.7.13, but I tried many other versions as well.
You need python 2.7.13 x86
After installation you can check it visibility for pykd with command pykd.info - it should show path to python. For python 2.7 it is commonly C:\windows\system32\python27.dll
Also had the same issue, in the end it depends on which windbg version you are using, and what python versions you have installed;
If it is windbg x86, you need python 32 bits installed.
If it is windbg x64, you need python 64 bits installed.
I did not have to add any specific version to the PATH, I have 3 versions of python in my system; python2.7x86, python2.7x64 and python3x64 and if I run !pykd.info in windbgx86 it recognizes both x86 pythons and if I run it in sindbgx64 it recognizes the x64 python.
If your !pykd.info does not list any python, you probably have them mixed up (you only have pythonx86 while running windbgx64, or you only have pythonx64 while running windbgx86).
I'd like to reset the python terminal command path to the pre-installed version 2.7 on OS X 10.11.3. I never had any path issues on my previous machine, whether it was installing packages to certain versions or avoiding breakages etc. The additions I made to my new machine shouldn't have altered how the python command is set (according to docs and the book I'm using). I don't consider myself a Terminal power-user. I appreciate any help. Details of those additions and what research I have already done follow:
Python 2.6 and 2.7 were pre-installed and the python command launched version 2.7 before I made any changes.
I installed Python 3.5.1 from python.org using python-3.5.1-macosx10.6.pkg, and at that stage python launched ver. 2.7 and python3 launched ver. 3.5.1. This is in-keeping with my previous machine and the book I'm using now: "Python 3 will be installed as /usr/local/bin/python3, leaving any existing Python 2 on your computer unchanged." (Introducing Python by Lubanovic)
I installed Anaconda 3 from continuum.io using the Python 3.5 graphical installer Anaconda3-2.5.0-MacOSX-x86_64.pkg, and following the walkthrough in Introducing Python: "Anaconda installs everything in its own directory (anaconda under your home directory). This means that it won't interfere with any versions of Python that might already be on your computer." The Read Me supports this: "The 'Install for me only' option will install anaconda to the default location, ~/anaconda."
While I am very familiar with certain packages within Anaconda, I have never used Anaconda before. Likewise I didn't think a second install of Python 3.5.1 in a unique directory would mask or conflict either of the other versions.
However, I suspect that this is where I went wrong. The Anaconda Read Me also states: "By default, this installer modifies your bash profile to put Anaconda in your PATH. To disable this, choose "Customize" at the "Installation Type" phase, and disable the "Modify PATH" option. If you do not do this, you will need to add ~/anaconda/bin to your PATH manually to run the commands, or run all anaconda commands explicitly from that path." Please bear in mind, this consideration is not found in the install walkthrough in Introducing Python. I didn't address this one way or the other, so the default was carried out by the installer.
At this stage, both python and python3 launch Python 3.5.1 from Anaconda 2.5.0; only python2.7 launches Python 2.7.
Perhaps there is some way to test how much trouble this might cause.
I haven't explicitly altered or created any aliases, any paths, or any other environment variables. Ned Deily provided thorough-going info in several QnAs. In QnA How to set default Python version in terminal on OS X 10.6.8? he specifies: "The python.org installers for Python 3.x on OS X do not select the shell script modification option by default. You can enable it at installation or you can later run the Update Shell Profile.command file in the corresponding Python x.x folder in the Applications folder. Or you can just manually edit the right profile." I haven't run Update Shell Profile.command of course. Moreover, this info is concurrent with the outcome from my initial 3.5.1 install, but seems contrary to the bash mod info provided in the Anaconda Read Me. But again, I don't know enough about the inner-workings to execute the correct prognosis.
I am to blame for not reconciling the Read Me with the walkthrough prior to the install. I have already researched uninstalling Anaconda, which looks like it creates breakages and hassles. Most of the related QnAs here are concerned with setting or changing the pre-installed system-friendly version to Python 3. After reading through a half-dozen of these QnAs I would be comfortable with performing that change, but I want to do the opposite. It's also possible that I should run tests or check the results of certain terminal commands prior to changing anything. I don't want to attempt anything (the inverse of instructions in a QnA, for example) without expert advice. For an expert I'm sure it's a minor point; thanks for your patience.
Using info provided by waitingkuo in QnA How to set default Python version in terminal on OS X 10.6.8? I have included the current state of my ~/.bash_profile:
# Setting PATH for Python 3.5
# The orginal version is saved in .bash_profile.pysave
PATH="/Library/Frameworks/Python.framework/Versions/3.5/bin:${PATH}"
export PATH
# added by Anaconda3 2.5.0 installer
export PATH="/Users/shawnchristopherburke/anaconda/bin:$PATH"
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
"~/.bash_profile" 8L, 267C
In QnA how to change default python version? Adam Vandenberg said that altering which version python launches might not break things in OS X: "Any system software would be using the full path to the system provided Python." That makes me feel better, but I would like to put things back the way they were to ensure compatibility, especially with pre-existing pathnames. Why would Anaconda not default to exercising caution the way python.org installs of Python 3 do? Anxiety is a factor; it is a new machine.
I understand even though I've written at length here, likely there are key details missing. Please let me know if there's any other info I can provide. I'm accustomed to using multiple versions of Python at will, with as few low-level adjustments as possible (first time I've ever looked at .bash_profile for example). So thanks in advance for the education to overcome this hang-up.
Is it possible to use system python in homebrew?
I have python 2.7.5 installed on my mac, but when I try to install any homebrew package with python in dependencies, it starts loading python 2.7.9.
It is important for me to use system python because of lots of installed python packages.
What version of python homebrew uses depends on two things:
Where the python alias points to.
What the python path is in the formula.
In most cases, homebrew forumlae simply use the python command, and does not specify a python path. If it does, then it is usually /usr/bin/python.
So, you can fix the problem in two ways:
Change the homebrew formulate to point to the right python interpreter of your choice.
Change where the python command points to.
The first option is problematic, since it means that you need to go into your Cellar folder, and alter things. This is not nice, and usually not required.
A better alternative is to point to the right python command. This is where pyenv comes in handy. pyenv is a command line tool that helps you manage different versions of python. Follow the instructions here:
https://github.com/yyuu/pyenv-installer
to install it.
Once that is done, change your python command to whatever version of python you'd like it to point to.
I'm currently doing some embedded systems programming. This was set up by somebody else a few years ago. So now I'm looking to upgrade to Python 2.7.2 to make things simpler because I have already run into two cases where what I coded wasn't supported.
What is currently running:
: uname -a
Linux host1 2.6.18-6-486 #1 Sun Feb 10 22:06:33 UTC 2008 i586 GNU/Linux
: python -v
Python 2.4.4
: pyversions -i
python2.4
So right now only 2.4 is installed.
I untarred python2.7.2 and when I go to that directory and run python27 setup.py install --home=/home/jhemilian and it seems like python2.4 doesn't seem to know the with...as statement syntax:
host1:/home/jhemilian/src/Python-2.7.2: python setup.py install --home=/home/jhe
milian
File "setup.py", line 361
with open(tmpfile) as fp:
^
SyntaxError: invalid syntax
Before I go figuring this out I first have a question: python itself is being used to install Python? What if I didn't have the first version of Python installed? I know it's shipped with most Linux but hypothetically -- how does such a seeming catch-22 like that work?
What I am looking to do is install python2.7 in a benign location, keeping the python command still as using Python 2.4 just in case the "legacy" software i'm running is dependent on it, and running python2.7 myscript.py et cetera when I want to run one of my newer scripts. Feel free to comment if there is a cleaner or more practical (or even safer!) way to do this.
I don't think it would make much sense to go replacing all the with statements with compatible try blocks. I've looked though the READMEs and online documentation but I can't seem to find a way to install Python without already having Python. Note that I DO NOT have internet connection, although if desirable or necessary I could. It would be great if somebody could point me in the right direction. Thanks!!
It's all right in the README...
You don't need to use python to install, in fact, you shouldn't...just:
./configure
make
make install
If you want to install in a specific dir, just follow what the README says:
Installing
To install the Python binary, library modules, shared library modules
(see below), include files, configuration files, and the manual page,
just type
make install
This will install all platform-independent files in subdirectories of
the directory given with the --prefix option to configure or to the
prefix' Make variable (default /usr/local). All binary and other
platform-specific files will be installed in subdirectories if the
directory given by --exec-prefix or theexec_prefix' Make variable
(defaults to the --prefix directory) is given.
If DESTDIR is set, it will be taken as the root directory of the
installation, and files will be installed into $(DESTDIR)$(prefix),
$(DESTDIR)$(exec_prefix), etc.
All subdirectories created will have Python's version number in their
name, e.g. the library modules are installed in
"/usr/local/lib/python/" by default, where is the
. release number (e.g. "2.1"). The Python binary is
installed as "python" and a hard link named "python" is
created. The only file not installed with a version number in its
name is the manual page, installed as "/usr/local/man/man1/python.1"
by default.
If you want to install multiple versions of Python see the section
below entitled "Installing multiple versions".
The only thing you may have to install manually is the Python mode for
Emacs found in Misc/python-mode.el. (But then again, more recent
versions of Emacs may already have it.) Follow the instructions that
came with Emacs for installation of site-specific files.
EDIT: virtualenv is apparently for already-installed Python versions. Disregard this recommendation.
I think what you want is virtualenv.
I haven't used it myself, but I understand this is what it's meant for.
From the website:
virtualenv is a tool to create isolated Python environments.
The basic problem being addressed is one of dependencies and versions, and indirectly permissions. Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python2.7/site-packages (or whatever your platform's standard location is), it's easy to end up in a situation where you unintentionally upgrade an application that shouldn't be upgraded.
EDIT: Upon review, I think you want Alberto's answer, so I voted him up for visibility.