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. --David
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
On 4 Nov 2013 03:00, "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.
Essentially what Greg said - we export many of the same symbols from both shared libraries, so if you try to load both CPython 2 and 3 into one process, the dynamic linker isn't going to be happy about it at all. Since making it work would be a lot of work for minimal benefit, the most that could realistically be done is to make it fail a little more gracefully (I believe that would need to be done on the Vim side of things, though). Cheers, Nick.
--David _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
On Nov 04, 2013, at 08:04 AM, Nick Coghlan wrote:
Since making it work would be a lot of work for minimal benefit, the most that could realistically be done is to make it fail a little more gracefully (I believe that would need to be done on the Vim side of things, though).
Right. I can't remember the details, but I've seen similar types of dual-plugin support in other applications. Generally it means you can *either* import Python 2 code or Python 3 code in a single process, but once you've fired up the first runtime, the application will prevent you from firing up the other. So yes, I think Vim would have to put that guard in, and I agree that there's not much benefit in trying to make this work in Python. -Barry
participants (4)
-
Barry Warsaw -
Gregory P. Smith -
Nick Coghlan -
R. David Murray