I came across this in the VIM documentation:

� � Vim can be built in four ways (:version output):
� � 1. No Python support � � � �(-python, -python3)
� � 2. Python 2 support only � �(+python or +python/dyn, -python3)
� � 3. Python 3 support only � �(-python, +python3 or +python3/dyn)
� � 4. Python 2 and 3 support � (+python/dyn, +python3/dyn)

� � Some more details on the special case 4:

� � When Python 2 and Python 3 are both supported they must be loaded dynamically.

� � When doing this on Linux/Unix systems and importing global symbols, this leads
� � to a crash when the second Python version is used. �So either global symbols
� � are loaded but only one Python version is activated, or no global symbols are
� � loaded. The latter makes Python's "import" fail on libraries that expect the
� � symbols to be provided by Vim.

I've never played with embedding Python. �Does this make sense to
anyone who has? �Is there some limitation in our embedding and/or
import machinery here, or is this more likely to be a shortcoming on
the VIM side?

Mostly I'm asking out of curiosity in hopes of learning something;
I doubt I'll have enough motivation to make time to work on solving this.

I'm not used to it being possible to have multiple different embedded Python interpreters in one process at all. The Python C API symbols exported by one python interpreter will conflict with another python interpreter. We don't provide isolation of interpreters within a process. IIRC, if you do have multiple even of the same version within a single process they are still all sharing the same python memory allocator pools and GIL and more.
">

(original) (raw)


On Sun, Nov 3, 2013 at 8:59 AM, R. David Murray <rdmurray@bitdance.com> wrote:
I came across this in the VIM documentation:

� � Vim can be built in four ways (:version output):
� � 1\. No Python support � � � �(-python, -python3)
� � 2\. Python 2 support only � �(+python or +python/dyn, -python3)
� � 3\. Python 3 support only � �(-python, +python3 or +python3/dyn)
� � 4\. Python 2 and 3 support � (+python/dyn, +python3/dyn)

� � Some more details on the special case 4:

� � When Python 2 and Python 3 are both supported they must be loaded dynamically.

� � When doing this on Linux/Unix systems and importing global symbols, this leads
� � to a crash when the second Python version is used. �So either global symbols
� � are loaded but only one Python version is activated, or no global symbols are
� � loaded. The latter makes Python's "import" fail on libraries that expect the
� � symbols to be provided by Vim.

I've never played with embedding Python. �Does this make sense to
anyone who has? �Is there some limitation in our embedding and/or
import machinery here, or is this more likely to be a shortcoming on
the VIM side?

Mostly I'm asking out of curiosity in hopes of learning something;
I doubt I'll have enough motivation to make time to work on solving this.

I'm not used to it being possible to have multiple different embedded Python interpreters in one process at all. The Python C API symbols exported by one python interpreter will conflict with another python interpreter. We don't provide isolation of interpreters within a process. IIRC, if you do have multiple even of the same version within a single process they are still all sharing the same python memory allocator pools and GIL and more.

That someone even went through the hoops to attempt to get vim to allow having some semblance of both python 2 and python 3 embedded dynamically at runtime seems like overkill to me.

Pick one and go with it. Vim should declare at some point in 2014 that the embedded Python in vim is now Python 3 only and move on. The rare users who actually use the embedded bazillion scripting languages within vim will need to update their code, ideally to be 2 and 3 compatible.

-gps