[vim] Vim is unable to automatically detect my Python version (#419)

[Markus Meskanen]

I installed Python 3.5 (tried with both 32- and 64-bit versions), but my Vim is unable to recognize the version.
Apparently I would have to recompile the whole Vim to work with any other version than Python 3.2.
Here are some of the errors I'm receiving, all of them basically leading up to Could not load library python32.dll, which I don't have because I'm using python35.dll.

This might not be a bug for you guys, but it's 2015 and every other text editor I've ever used automatically recognizes and can run any Python version I have installed.
I personally think it would be about time for Vim to upgrade its system a little, so it wouldn't be necessary for an everyday user to learn how to compile Vim and change its Python version.

If there's something I've missed, please elaborate, I'm just a beginner with Vim. But if this is the case and no change is going to be made, I feel like Vim is not too friendly for Python developers, and I will have to revert to an other editor. Which would be unfortunate, because Vim seems like an awesome text editor, but some of its features are still from 1990. Just my opinion.

—
Reply to this email directly or view it on GitHub.

[Nikolay Pavlov]

2015-09-16 0:14 GMT+03:00 Markus Meskanen <vim-dev...@256bit.org>:

I installed Python 3.5 (tried with both 32- and 64-bit versions), but my Vim is unable to recognize the version.
Apparently I would have to recompile the whole Vim to work with any other version than Python 3.2.
Here are some of the errors I'm receiving, all of them basically leading up to Could not load library python32.dll, which I don't have because I'm using python35.dll.

This might not be a bug for you guys, but it's 2015 and every other text editor I've ever used automatically recognizes and can run any Python version I have installed.

Which editors? Some of them use Python as an external executable and use some IPC method for communication and thus do not require recompiling. Some are written in Python (which has good backward compatibility inside one major version) and do not require recompiling as well.

Vim on the other side is *embedding* Python using its C API. It cannot possibly use any Python version, given that “backward compatibility” here sometimes means that “we can replace C function with a C macros”. This is rather unique: even NeoVim prefers to run python as a child process and communicate with it using sockets, thus being version-independent as long as neovim module runs on given Python version and implementation.

 

I personally think it would be about time for Vim to upgrade its system a little, so it wouldn't be necessary for an everyday user to learn how to compile Vim and change its Python version.

C API is the fastest way to work with Python. Everything else will be slower. Also this code is already written.

 

If there's something I've missed, please elaborate, I'm just a beginner with Vim. But if this is the case and no change is going to be made, I feel like Vim is not too friendly for Python developers, and I will have to revert to an other editor. Which would be unfortunate, because Vim seems like an awesome text editor, but some of its features are still from 1990. Just my opinion.

—
Reply to this email directly or view it on GitHub.

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Markus Meskanen]

Almost all editors afaik... Sublime, Emacs, Komodo Edit, even Notepad++. Sure most of them need some configurations, but usually it's just pointing the editor to your Python.exe or something similar.

I believe when you say that C API is the fastest way, but I can use Python just fine with all other editors without having to worry about too much. If I have to recompile the whole text editor just to change my Python version, it's not really intuitive and I'm not going to stick around with that editor for too long, regardless of how fast something is. You wouldn't drive a fast car with no wheel.

[Weiming]

I am havin the same pleblem now. I have installed python27 (64 bit) and python35 (32 bit) in my computer, and they both work well. Recently, I start to use VIM. However, I unintentionally installed VIM 32 bit, and here came the tragedy: VIM 32 bit is NEITHER compatible with python27 64 bit which is now obvious, NOR with python35 32 bit since VIM seems to search python34.lib by default.

being frustrated......

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

[Christian Brabandt]

you should be able to compile vim against python3.5 That should work then.

—
You are receiving this because you commented.

Reply to this email directly or view it on GitHub

[Christian Brabandt]

anyway, I think this issue can be closed

—
You are receiving this because you commented.

Reply to this email directly or view it on GitHub

[Weiming]

However, if the executable installer is used, the installer tries to find python34.lib by default. There seems to be no way of customizing it. :(

Still not smooth with open sources....

—
You are receiving this because you commented.

Reply to this email directly or view it on GitHub

[Markus Meskanen]

While I don't expect Vim to become an easy-to-use text editor for beginners or anything, the current Python support simply isn't enough for a standard coder. Vim doesn't support multiple Python versions, so you have to compile multiple versions of Vim. And every time you update your Python, you must recompile Vim. Other editors simply do Python better.

—
You are receiving this because you commented.

Reply to this email directly or view it on GitHub

[Weiming]

Well, I don't disagree with you. But please note that Vim can actually support python2X and python3X at the same time. I am still messing around with it.

No matter what you use, good luck !

—
You are receiving this because you commented.

Reply to this email directly or view it on GitHub

[Wang Shidong]

@Weiming-Hu as I know vim can not use python2 and python3 at same time,it is different with neovim.
neovim use local python as executale.
so I have two ways to manager my neovim's python interface

let g:python_host_prog = '/usr/bin/python2.7'
let g:python3_host_prog = '/usr/bin/python3.5'

and

let g:python_host_prog = '/usr/bin/python2.7'
let g:python3_host_prog = '/usr/bin/python3.4'

—
You are receiving this because you commented.

Reply to this email directly or view it on GitHub

[K.Takata]

To support multiple python versions, we need to change if_python drastically.
The linked python version is fixed at compile time, because the API of
pythonXX.dll will be changed between different versions.

Currently, (g)vim.exe is linked to pythonXX.dll directly, so we cannot support
automatic version detection. E.g.:

gvim.exe -+- python27.dll
          |
          `- python34.dll

To support automatic version detection, maybe we need different if_python DLL
for each version of python DLL. E.g.:

gvim.exe -+- if_py26.dll -- python26.dll
          |- if_py27.dll -- python27.dll
          |
          |- if_py33.dll -- python33.dll
          |- if_py34.dll -- python34.dll
          `- if_py35.dll -- python35.dll

(I don't know how the other editors work around this.)

Vim can actually support python2X and python3X at the same time.

It doesn't mean Vim can easily support python 3.4 and 3.5 at the same time.
They are totally different things.

—
You are receiving this because you commented.

Reply to this email directly or view it on GitHub

[Weiming]

@k-takata Thank you for your comment. It is indeed what I mean. The linked python version is linked at compile time.

And could you, or anybody else, please help me with this? Below is part of the prints after I run :version in my vim.

Vim says it has suppport of python and python3.** I know I am using a 32 bit vim, and 64 bit python/python3, which aren't compatible.** Then, if I run :python print(1), I am supposed to get error like "unable to link ***.dll". However, my vim just crush and quit....... Anybody has an idea?

Thank you!

—
You are receiving this because you commented.

Reply to this email directly or view it on GitHub

[Jacky Liu]

-----------------------------------------------------------------

You can have the full power of Python from within your Vim only if Vim and Python can run *in the same thread with the same memory space*, this can only be achieved by *embedding* Python into Vim, not invoking it.

The dynamic run-time solution you mentioned is awfully slow and inefficient. Can you imagine an application's UI starts its back-end as an external process and then use a pipe or socket to communicate with it later? Its awful. UI and the back-end should be within the same process. Emacs even try to do data translation between Python and Elisp with its Pymacs, again, its awful, hopeless. Vim should never do that.

I suppose Python itself doesn't have good support for multiple versions within the same environment, try creating a Py2 list inside Py3. You can build a py3-enabled Vim and run py2 as an external process, or vice versa. You can have both Vims on your system and choose between them each time accordingly, I suppose you won't definitely need one project of yours half in Py2 and half in Py3.

[Christian Brabandt]

https://groups.google.com/d/msg/vim_dev/bg1MWfZfPAg/-PB3RXUSAwAJ explains the issue.

@Weiming-Hu looks like your Vim tried to load a wrong python dll, leading to a segfault. This is known to happen, when you compile your own vim with a different compiler than the python version, e.g. mingw versus visual studio.

I am closing this now.

—

You are receiving this because you commented.

Reply to this email directly or view it on GitHub

[Christian Brabandt]

Closed #419.

—
You are receiving this because you commented.

Reply to this email directly or view it on GitHub

[Nikolay Aleksandrovich Pavlov]

2016-04-27 18:30 GMT+03:00 Jacky Liu <bluege...@gmail.com>:
> On Tuesday, April 26, 2016 at 4:29:07 PM UTC+8, Markus Meskanen wrote:
>> While I don't expect Vim to become an easy-to-use text editor for beginners or anything, the current Python support simply isn't enough for a standard coder. Vim doesn't support multiple Python versions, so you have to compile multiple versions of Vim. And every time you update your Python, you must recompile Vim. Other editors simply do Python better.
>>
>>
>> —
>> You are receiving this because you commented.
>> Reply to this email directly or view it on GitHub
>
> -----------------------------------------------------------------
>
> You can have the full power of Python from within your Vim only if Vim and Python can run *in the same thread with the same memory space*, this can only be achieved by *embedding* Python into Vim, not invoking it.
>
> The dynamic run-time solution you mentioned is awfully slow and inefficient. Can you imagine an application's UI starts its back-end as an external process and then use a pipe or socket to communicate with it later? Its awful. UI and the back-end should be within the same process. Emacs even try to do data translation between Python and Elisp with its Pymacs, again, its awful, hopeless. Vim should never do that.

Both works well enough in Neovim. Though terminal UI is *now* part of
the same executable (will be different one later), Python communicates
through msgpack over a socket. This thing is obviously slower and in
some cases people need to do optimizations, but most of time this is
good enough. Also there are UIs other then terminal one and they all
use pipes or sockets. Unlike for Python support I did not hear about
problems with UI lags (though maybe because +python users are more
common here then GUI users; on the other side UI authors did not raise
issues regarding communication protocol speed so at least they think
that nothing can be done to speed up, at most they know how to write
their UI without it lagging).

Also this is how most web applications work. UI is in browser. Backend
is on server. And between them you have lots of routers which makes
the whole thing much slower then if UI communicates with Neovim
through msgpack. Still they work, using different hacks for different
situations (from having most of the code on the frontend, only sending
a few commands like “save {big blob}” to the backend once in a while,
to requiring client have his own server with controlled latency).

>
> I suppose Python itself doesn't have good support for multiple versions within the same environment, try creating a Py2 list inside Py3. You can build a py3-enabled Vim and run py2 as an external process, or vice versa. You can have both Vims on your system and choose between them each time accordingly, I suppose you won't definitely need one project of yours half in Py2 and half in Py3.

Python itself (though not Python, but dynamic library loader,
ld-linux.so) has fine support here. Just distribution maintainers do
not bother compiling Python with --enable-shared, so python2 and
python3 effectively cannot be used together unless you go compile them
yourself.

On Gentoo --enable-shared is used, so no such problems here.

Note though that even if you have +python/dyn and +python3/dyn working
at the same time this does not mean that you can use single PyObject
in both interpreters. In this case :python environment is just as
isolated from :python3 as :lua is. So with vim.bindeval the fastest
way of transferring data is using Vim container objects (lists,
dictionaries, but not partials: last is read-only after creation but
still is a container (using list or dictionary should be faster
though)).

[Jacky Liu]

>
> Both works well enough in Neovim. Though terminal UI is *now* part of
> the same executable (will be different one later), Python communicates
> through msgpack over a socket. This thing is obviously slower and in
> some cases people need to do optimizations, but most of time this is
> good enough. Also there are UIs other then terminal one and they all
> use pipes or sockets. Unlike for Python support I did not hear about
> problems with UI lags (though maybe because +python users are more
> common here then GUI users; on the other side UI authors did not raise
> issues regarding communication protocol speed so at least they think
> that nothing can be done to speed up, at most they know how to write
> their UI without it lagging).
>
> Also this is how most web applications work. UI is in browser. Backend
> is on server. And between them you have lots of routers which makes
> the whole thing much slower then if UI communicates with Neovim
> through msgpack. Still they work, using different hacks for different
> situations (from having most of the code on the frontend, only sending
> a few commands like “save {big blob}” to the backend once in a while,
> to requiring client have his own server with controlled latency).
>

Wait a minute ... I haven't tried neovim yet but I'm having my eye on it. If neovim runs Python as an external process, then does Python have the 'vim' module anymore ? Will Python be able to do 'import vim' and use its utilities within its environment?

Please elaborate, thanks.

[Nikolay Aleksandrovich Pavlov]

What makes you think there is something that may prevent `import vim`
from working? With python import hooks you may create any module you
like without actually having it on the filesystem, or having it in C
code like Vim. And really you do not even need import hooks to do
`import sys; sys.modules['vim'] = my_vim_module`, that can mock vim
module even in Vim itself if done before first import.

Of course, Neovim emulation of `vim` module has some different
behaviour (not fully compatible) and has completely different source
code. But yet many code written for Vim works.