2016-08-29 22:49:24 +02:00
|
|
|
/* vi:set ts=8 sts=4 sw=4 noet:
|
2010-07-17 21:19:38 +02:00
|
|
|
*
|
|
|
|
* VIM - Vi IMproved by Bram Moolenaar
|
|
|
|
*
|
|
|
|
* Do ":help uganda" in Vim to read copying and usage conditions.
|
|
|
|
* Do ":help credits" in Vim to see a list of people who contributed.
|
|
|
|
* See README.txt for an overview of the Vim source code.
|
|
|
|
*/
|
|
|
|
/*
|
|
|
|
* Python extensions by Paul Moore.
|
|
|
|
* Changes for Unix by David Leonard.
|
|
|
|
*
|
|
|
|
* This consists of four parts:
|
|
|
|
* 1. Python interpreter main program
|
|
|
|
* 2. Python output stream: writes output via [e]msg().
|
|
|
|
* 3. Implementation of the Vim module for Python
|
|
|
|
* 4. Utility functions for handling the interface between Vim and Python.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Roland Puntaier 2009/sept/16:
|
|
|
|
* Adaptations to support both python3.x and python2.x
|
|
|
|
*/
|
|
|
|
|
2019-12-04 21:24:53 +01:00
|
|
|
// uncomment this if used with the debug version of python
|
|
|
|
// #define Py_DEBUG
|
|
|
|
// Note: most of time you can add -DPy_DEBUG to CFLAGS in place of uncommenting
|
|
|
|
// uncomment this if used with the debug version of python, but without its
|
|
|
|
// allocator
|
|
|
|
// #define Py_DEBUG_NO_PYMALLOC
|
2010-07-17 21:19:38 +02:00
|
|
|
|
|
|
|
#include "vim.h"
|
|
|
|
|
|
|
|
#include <limits.h>
|
|
|
|
|
2019-02-17 17:44:42 +01:00
|
|
|
#if defined(MSWIN) && defined(HAVE_FCNTL_H)
|
2010-07-17 21:19:38 +02:00
|
|
|
# undef HAVE_FCNTL_H
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef _DEBUG
|
|
|
|
# undef _DEBUG
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef F_BLANK
|
|
|
|
# undef F_BLANK
|
|
|
|
#endif
|
|
|
|
|
2022-11-04 22:38:11 +00:00
|
|
|
#ifdef HAVE_DUP
|
|
|
|
# undef HAVE_DUP
|
|
|
|
#endif
|
2016-02-16 15:06:59 +01:00
|
|
|
#ifdef HAVE_STRFTIME
|
|
|
|
# undef HAVE_STRFTIME
|
|
|
|
#endif
|
|
|
|
#ifdef HAVE_STRING_H
|
|
|
|
# undef HAVE_STRING_H
|
|
|
|
#endif
|
|
|
|
#ifdef HAVE_PUTENV
|
|
|
|
# undef HAVE_PUTENV
|
|
|
|
#endif
|
2010-07-18 18:04:50 +02:00
|
|
|
#ifdef HAVE_STDARG_H
|
2019-12-04 21:24:53 +01:00
|
|
|
# undef HAVE_STDARG_H // Python's config.h defines it as well.
|
2010-07-18 18:04:50 +02:00
|
|
|
#endif
|
2019-12-04 21:24:53 +01:00
|
|
|
#ifdef _POSIX_C_SOURCE // defined in feature.h
|
2010-07-17 21:19:38 +02:00
|
|
|
# undef _POSIX_C_SOURCE
|
|
|
|
#endif
|
2010-07-18 18:04:50 +02:00
|
|
|
#ifdef _XOPEN_SOURCE
|
2019-12-04 21:24:53 +01:00
|
|
|
# undef _XOPEN_SOURCE // pyconfig.h defines it as well.
|
2010-07-18 18:04:50 +02:00
|
|
|
#endif
|
2010-07-17 21:19:38 +02:00
|
|
|
|
2013-06-10 18:36:24 +02:00
|
|
|
#define PY_SSIZE_T_CLEAN
|
|
|
|
|
patch 9.0.1776: No support for stable Python 3 ABI
Problem: No support for stable Python 3 ABI
Solution: Support Python 3 stable ABI
Commits:
1) Support Python 3 stable ABI to allow mixed version interoperatbility
Vim currently supports embedding Python for use with plugins, and the
"dynamic" linking option allows the user to specify a locally installed
version of Python by setting `pythonthreedll`. However, one caveat is
that the Python 3 libs are not binary compatible across minor versions,
and mixing versions can potentially be dangerous (e.g. let's say Vim was
linked against the Python 3.10 SDK, but the user sets `pythonthreedll`
to a 3.11 lib). Usually, nothing bad happens, but in theory this could
lead to crashes, memory corruption, and other unpredictable behaviors.
It's also difficult for the user to tell something is wrong because Vim
has no way of reporting what Python 3 version Vim was linked with.
For Vim installed via a package manager, this usually isn't an issue
because all the dependencies would already be figured out. For prebuilt
Vim binaries like MacVim (my motivation for working on this), AppImage,
and Win32 installer this could potentially be an issue as usually a
single binary is distributed. This is more tricky when a new Python
version is released, as there's a chicken-and-egg issue with deciding
what Python version to build against and hard to keep in sync when a new
Python version just drops and we have a mix of users of different Python
versions, and a user just blindly upgrading to a new Python could lead to
bad interactions with Vim.
Python 3 does have a solution for this problem: stable ABI / limited API
(see https://docs.python.org/3/c-api/stable.html). The C SDK limits the
API to a set of functions that are promised to be stable across
versions. This pull request adds an ifdef config that allows us to turn
it on when building Vim. Vim binaries built with this option should be
safe to freely link with any Python 3 libraies without having the
constraint of having to use the same minor version.
Note: Python 2 has no such concept and this doesn't change how Python 2
integration works (not that there is going to be a new version of Python
2 that would cause compatibility issues in the future anyway).
---
Technical details:
======
The stable ABI can be accessed when we compile with the Python 3 limited
API (by defining `Py_LIMITED_API`). The Python 3 code (in `if_python3.c`
and `if_py_both.h`) would now handle this and switch to limited API
mode. Without it set, Vim will still use the full API as before so this
is an opt-in change.
The main difference is that `PyType_Object` is now an opaque struct that
we can't directly create "static types" out of, and we have to create
type objects as "heap types" instead. This is because the struct is not
stable and changes from version to version (e.g. 3.8 added a
`tp_vectorcall` field to it). I had to change all the types to be
allocated on the heap instead with just a pointer to them.
Other functions are also simply missing in limited API, or they are
introduced too late (e.g. `PyUnicode_AsUTF8AndSize` in 3.10) to it that
we need some other ways to do the same thing, so I had to abstract a few
things into macros, and sometimes re-implement functions like
`PyObject_NEW`.
One caveat is that in limited API, `OutputType` (used for replacing
`sys.stdout`) no longer inherits from `PyStdPrinter_Type` which I don't
think has any real issue other than minor differences in how they
convert to a string and missing a couple functions like `mode()` and
`fileno()`.
Also fixed an existing bug where `tp_basicsize` was set incorrectly for
`BufferObject`, `TabListObject, `WinListObject`.
Technically, there could be a small performance drop, there is a little
more indirection with accessing type objects, and some APIs like
`PyUnicode_AsUTF8AndSize` are missing, but in practice I didn't see any
difference, and any well-written Python plugin should try to avoid
excessing callbacks to the `vim` module in Python anyway.
I only tested limited API mode down to Python 3.7, which seemes to
compile and work fine. I haven't tried earlier Python versions.
2) Fix PyIter_Check on older Python vers / type##Ptr unused warning
For PyIter_Check, older versions exposed them as either macros (used in
full API), or a function (for use in limited API). A previous change
exposed PyIter_Check to the dynamic build because Python just moved it
to function-only in 3.10 anyway. Because of that, just make sure we
always grab the function in dynamic builds in earlier versions since
that's what Python eventually did anyway.
3) Move Py_LIMITED_API define to configure script
Can now use --with-python-stable-abi flag to customize what stable ABI
version to target. Can also use an env var to do so as well.
4) Show +python/dyn-stable in :version, and allow has() feature query
Not sure if the "/dyn-stable" suffix would break things, or whether we
should do it another way. Or just don't show it in version and rely on
has() feature checking.
5) Documentation first draft. Still need to implement v:python3_version
6) Fix PyIter_Check build breaks when compiling against Python 3.8
7) Add CI coverage stable ABI on Linux/Windows / make configurable on Windows
This adds configurable options for Windows make files (both MinGW and
MSVC). CI will also now exercise both traditional full API and stable
ABI for Linux and Windows in the matrix for coverage.
Also added a "dynamic" option to Linux matrix as a drive-by change to
make other scripting languages like Ruby / Perl testable under both
static and dynamic builds.
8) Fix inaccuracy in Windows docs
Python's own docs are confusing but you don't actually want to use
`python3.dll` for the dynamic linkage.
9) Add generated autoconf file
10) Add v:python3_version support
This variable indicates the version of Python3 that Vim was built
against (PY_VERSION_HEX), and will be useful to check whether the Python
library you are loading in dynamically actually fits it. When built with
stable ABI, it will be the limited ABI version instead
(`Py_LIMITED_API`), which indicates the minimum version of Python 3 the
user should have, rather than the exact match. When stable ABI is used,
we won't be exposing PY_VERSION_HEX in this var because it just doesn't
seem necessary to do so (the whole point of stable ABI is the promise
that it will work across versions), and I don't want to confuse the user
with too many variables.
Also, cleaned up some documentation, and added help tags.
11) Fix Python 3.7 compat issues
Fix a couple issues when using limited API < 3.8
- Crash on exit: In Python 3.7, if a heap-allocated type is destroyed
before all instances are, it would cause a crash later. This happens
when we destroyed `OptionsType` before calling `Py_Finalize` when
using the limited API. To make it worse, later versions changed the
semantics and now each instance has a strong reference to its own type
and the recommendation has changed to have each instance de-ref its
own type and have its type in GC traversal. To avoid dealing with
these cross-version variations, we just don't free the heap type. They
are static types in non-limited-API anyway and are designed to last
through the entirety of the app, and we also don't restart the Python
runtime and therefore do not need it to have absolutely 0 leaks.
See:
- https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-c-api
- https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api
- PyIter_Check: This function is not provided in limited APIs older than
3.8. Previously I was trying to mock it out using manual
PyType_GetSlot() but it was brittle and also does not actually work
properly for static types (it will generate a Python error). Just
return false. It does mean using limited API < 3.8 is not recommended
as you lose the functionality to handle iterators, but from playing
with plugins I couldn't find it to be an issue.
- Fix loading of PyIter_Check so it will be done when limited API < 3.8.
Otherwise loading a 3.7 Python lib will fail even if limited API was
specified to use it.
12) Make sure to only load `PyUnicode_AsUTF8AndSize` in needed in limited API
We don't use this function unless limited API >= 3.10, but we were
loading it regardless. Usually it's ok in Unix-like systems where Python
just has a single lib that we load from, but in Windows where there is a
separate python3.dll this would not work as the symbol would not have
been exposed in this more limited DLL file. This makes it much clearer
under what condition is this function needed.
closes: #12032
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
2023-08-20 21:18:38 +02:00
|
|
|
#ifdef Py_LIMITED_API
|
|
|
|
# define USE_LIMITED_API // Using Python 3 limited ABI
|
|
|
|
#endif
|
|
|
|
|
2010-07-17 21:19:38 +02:00
|
|
|
#include <Python.h>
|
2013-06-10 18:36:24 +02:00
|
|
|
|
2019-12-04 21:24:53 +01:00
|
|
|
#undef main // Defined in python.h - aargh
|
|
|
|
#undef HAVE_FCNTL_H // Clash with os_win32.h
|
2010-07-17 21:19:38 +02:00
|
|
|
|
2019-12-04 21:24:53 +01:00
|
|
|
// The "surrogateescape" error handler is new in Python 3.1
|
2011-07-15 15:54:44 +02:00
|
|
|
#if PY_VERSION_HEX >= 0x030100f0
|
|
|
|
# define CODEC_ERROR_HANDLER "surrogateescape"
|
|
|
|
#else
|
|
|
|
# define CODEC_ERROR_HANDLER NULL
|
|
|
|
#endif
|
|
|
|
|
2022-11-05 14:05:31 +00:00
|
|
|
// Suppress Python 3.11 depreciations to see useful warnings
|
2023-08-11 22:38:48 +02:00
|
|
|
#ifdef __GNUC__
|
|
|
|
# pragma GCC diagnostic push
|
|
|
|
# pragma GCC diagnostic ignored "-Wdeprecated-declarations"
|
2022-11-05 14:05:31 +00:00
|
|
|
#endif
|
|
|
|
|
2019-12-04 21:24:53 +01:00
|
|
|
// Python 3 does not support CObjects, always use Capsules
|
2012-06-29 16:28:28 +02:00
|
|
|
#define PY_USE_CAPSULE
|
|
|
|
|
2020-12-21 16:03:02 +01:00
|
|
|
#define ERRORS_DECODE_ARG CODEC_ERROR_HANDLER
|
|
|
|
#define ERRORS_ENCODE_ARG ERRORS_DECODE_ARG
|
|
|
|
|
2010-07-24 23:51:45 +02:00
|
|
|
#define PyInt Py_ssize_t
|
2013-07-03 18:49:17 +02:00
|
|
|
#ifndef PyString_Check
|
|
|
|
# define PyString_Check(obj) PyUnicode_Check(obj)
|
|
|
|
#endif
|
2013-07-09 17:30:55 +02:00
|
|
|
#define PyString_FromString(repr) \
|
2020-12-21 16:03:02 +01:00
|
|
|
PyUnicode_Decode(repr, STRLEN(repr), ENC_OPT, ERRORS_DECODE_ARG)
|
2013-05-30 12:40:39 +02:00
|
|
|
#define PyString_FromFormat PyUnicode_FromFormat
|
2023-10-11 21:27:06 +02:00
|
|
|
#ifdef PyUnicode_FromFormat
|
|
|
|
# define Py_UNICODE_USE_UCS_FUNCTIONS
|
|
|
|
#endif
|
2013-07-03 18:49:17 +02:00
|
|
|
#ifndef PyInt_Check
|
|
|
|
# define PyInt_Check(obj) PyLong_Check(obj)
|
|
|
|
#endif
|
2012-09-21 13:46:06 +02:00
|
|
|
#define PyInt_FromLong(i) PyLong_FromLong(i)
|
|
|
|
#define PyInt_AsLong(obj) PyLong_AsLong(obj)
|
2013-04-24 13:39:15 +02:00
|
|
|
#define Py_ssize_t_fmt "n"
|
2013-05-30 13:01:18 +02:00
|
|
|
#define Py_bytes_fmt "y"
|
2010-07-24 23:51:45 +02:00
|
|
|
|
2014-01-14 16:36:51 +01:00
|
|
|
#define PyIntArgFunc ssizeargfunc
|
|
|
|
#define PyIntObjArgProc ssizeobjargproc
|
|
|
|
|
2014-03-30 16:11:43 +02:00
|
|
|
/*
|
|
|
|
* PySlice_GetIndicesEx(): first argument type changed from PySliceObject
|
|
|
|
* to PyObject in Python 3.2 or later.
|
|
|
|
*/
|
|
|
|
#if PY_VERSION_HEX >= 0x030200f0
|
|
|
|
typedef PyObject PySliceObject_T;
|
|
|
|
#else
|
|
|
|
typedef PySliceObject PySliceObject_T;
|
|
|
|
#endif
|
|
|
|
|
2022-02-07 13:54:01 +00:00
|
|
|
#ifndef MSWIN
|
|
|
|
# define HINSTANCE void *
|
|
|
|
#endif
|
|
|
|
#if defined(DYNAMIC_PYTHON3) || defined(MSWIN)
|
|
|
|
static HINSTANCE hinstPy3 = 0; // Instance of python.dll
|
|
|
|
#endif
|
|
|
|
|
2011-02-25 15:18:50 +01:00
|
|
|
#if defined(DYNAMIC_PYTHON3) || defined(PROTO)
|
2010-07-17 21:19:38 +02:00
|
|
|
|
2023-10-11 21:27:06 +02:00
|
|
|
# ifdef MSWIN
|
|
|
|
# define load_dll vimLoadLib
|
|
|
|
# define close_dll FreeLibrary
|
|
|
|
# define symbol_from_dll GetProcAddress
|
|
|
|
# define load_dll_error GetWin32Error
|
|
|
|
# else
|
2010-08-09 22:06:13 +02:00
|
|
|
# include <dlfcn.h>
|
|
|
|
# define FARPROC void*
|
2010-11-16 19:26:02 +01:00
|
|
|
# if defined(PY_NO_RTLD_GLOBAL) && defined(PY3_NO_RTLD_GLOBAL)
|
2010-08-09 22:06:13 +02:00
|
|
|
# define load_dll(n) dlopen((n), RTLD_LAZY)
|
|
|
|
# else
|
|
|
|
# define load_dll(n) dlopen((n), RTLD_LAZY|RTLD_GLOBAL)
|
|
|
|
# endif
|
|
|
|
# define close_dll dlclose
|
|
|
|
# define symbol_from_dll dlsym
|
2021-07-24 13:57:29 +02:00
|
|
|
# define load_dll_error dlerror
|
2010-08-09 22:06:13 +02:00
|
|
|
# endif
|
2010-07-17 21:19:38 +02:00
|
|
|
/*
|
|
|
|
* Wrapper defines
|
|
|
|
*/
|
2010-08-09 22:06:13 +02:00
|
|
|
# undef PyArg_Parse
|
2010-07-17 21:19:38 +02:00
|
|
|
# define PyArg_Parse py3_PyArg_Parse
|
2010-08-09 22:06:13 +02:00
|
|
|
# undef PyArg_ParseTuple
|
2010-07-17 21:19:38 +02:00
|
|
|
# define PyArg_ParseTuple py3_PyArg_ParseTuple
|
2011-06-19 00:27:51 +02:00
|
|
|
# define PyMem_Free py3_PyMem_Free
|
2012-06-29 12:54:53 +02:00
|
|
|
# define PyMem_Malloc py3_PyMem_Malloc
|
2010-07-17 21:19:38 +02:00
|
|
|
# define PyDict_SetItemString py3_PyDict_SetItemString
|
|
|
|
# define PyErr_BadArgument py3_PyErr_BadArgument
|
|
|
|
# define PyErr_Clear py3_PyErr_Clear
|
2013-06-23 13:46:40 +02:00
|
|
|
# define PyErr_Format py3_PyErr_Format
|
2013-02-20 16:09:43 +01:00
|
|
|
# define PyErr_PrintEx py3_PyErr_PrintEx
|
2010-07-17 21:19:38 +02:00
|
|
|
# define PyErr_NoMemory py3_PyErr_NoMemory
|
|
|
|
# define PyErr_Occurred py3_PyErr_Occurred
|
|
|
|
# define PyErr_SetNone py3_PyErr_SetNone
|
|
|
|
# define PyErr_SetString py3_PyErr_SetString
|
2013-05-15 15:35:09 +02:00
|
|
|
# define PyErr_SetObject py3_PyErr_SetObject
|
2013-06-10 21:27:29 +02:00
|
|
|
# define PyErr_ExceptionMatches py3_PyErr_ExceptionMatches
|
2010-07-17 21:19:38 +02:00
|
|
|
# define PyEval_InitThreads py3_PyEval_InitThreads
|
|
|
|
# define PyEval_RestoreThread py3_PyEval_RestoreThread
|
|
|
|
# define PyEval_SaveThread py3_PyEval_SaveThread
|
|
|
|
# define PyGILState_Ensure py3_PyGILState_Ensure
|
|
|
|
# define PyGILState_Release py3_PyGILState_Release
|
|
|
|
# define PyLong_AsLong py3_PyLong_AsLong
|
|
|
|
# define PyLong_FromLong py3_PyLong_FromLong
|
|
|
|
# define PyList_GetItem py3_PyList_GetItem
|
|
|
|
# define PyList_Append py3_PyList_Append
|
2013-06-10 21:27:29 +02:00
|
|
|
# define PyList_Insert py3_PyList_Insert
|
2010-07-17 21:19:38 +02:00
|
|
|
# define PyList_New py3_PyList_New
|
|
|
|
# define PyList_SetItem py3_PyList_SetItem
|
|
|
|
# define PyList_Size py3_PyList_Size
|
2012-06-29 12:54:53 +02:00
|
|
|
# define PySequence_Check py3_PySequence_Check
|
|
|
|
# define PySequence_Size py3_PySequence_Size
|
|
|
|
# define PySequence_GetItem py3_PySequence_GetItem
|
2013-05-30 13:01:18 +02:00
|
|
|
# define PySequence_Fast py3_PySequence_Fast
|
2012-06-29 12:54:53 +02:00
|
|
|
# define PyTuple_Size py3_PyTuple_Size
|
|
|
|
# define PyTuple_GetItem py3_PyTuple_GetItem
|
2018-07-04 22:03:25 +02:00
|
|
|
# if PY_VERSION_HEX >= 0x030601f0
|
|
|
|
# define PySlice_AdjustIndices py3_PySlice_AdjustIndices
|
|
|
|
# define PySlice_Unpack py3_PySlice_Unpack
|
|
|
|
# endif
|
|
|
|
# undef PySlice_GetIndicesEx
|
2010-07-17 21:19:38 +02:00
|
|
|
# define PySlice_GetIndicesEx py3_PySlice_GetIndicesEx
|
|
|
|
# define PyImport_ImportModule py3_PyImport_ImportModule
|
|
|
|
# define PyObject_Init py3__PyObject_Init
|
|
|
|
# define PyDict_New py3_PyDict_New
|
|
|
|
# define PyDict_GetItemString py3_PyDict_GetItemString
|
2012-06-29 12:54:53 +02:00
|
|
|
# define PyDict_Next py3_PyDict_Next
|
|
|
|
# define PyMapping_Check py3_PyMapping_Check
|
2013-07-03 18:49:17 +02:00
|
|
|
# ifndef PyMapping_Keys
|
|
|
|
# define PyMapping_Keys py3_PyMapping_Keys
|
|
|
|
# endif
|
patch 9.0.1776: No support for stable Python 3 ABI
Problem: No support for stable Python 3 ABI
Solution: Support Python 3 stable ABI
Commits:
1) Support Python 3 stable ABI to allow mixed version interoperatbility
Vim currently supports embedding Python for use with plugins, and the
"dynamic" linking option allows the user to specify a locally installed
version of Python by setting `pythonthreedll`. However, one caveat is
that the Python 3 libs are not binary compatible across minor versions,
and mixing versions can potentially be dangerous (e.g. let's say Vim was
linked against the Python 3.10 SDK, but the user sets `pythonthreedll`
to a 3.11 lib). Usually, nothing bad happens, but in theory this could
lead to crashes, memory corruption, and other unpredictable behaviors.
It's also difficult for the user to tell something is wrong because Vim
has no way of reporting what Python 3 version Vim was linked with.
For Vim installed via a package manager, this usually isn't an issue
because all the dependencies would already be figured out. For prebuilt
Vim binaries like MacVim (my motivation for working on this), AppImage,
and Win32 installer this could potentially be an issue as usually a
single binary is distributed. This is more tricky when a new Python
version is released, as there's a chicken-and-egg issue with deciding
what Python version to build against and hard to keep in sync when a new
Python version just drops and we have a mix of users of different Python
versions, and a user just blindly upgrading to a new Python could lead to
bad interactions with Vim.
Python 3 does have a solution for this problem: stable ABI / limited API
(see https://docs.python.org/3/c-api/stable.html). The C SDK limits the
API to a set of functions that are promised to be stable across
versions. This pull request adds an ifdef config that allows us to turn
it on when building Vim. Vim binaries built with this option should be
safe to freely link with any Python 3 libraies without having the
constraint of having to use the same minor version.
Note: Python 2 has no such concept and this doesn't change how Python 2
integration works (not that there is going to be a new version of Python
2 that would cause compatibility issues in the future anyway).
---
Technical details:
======
The stable ABI can be accessed when we compile with the Python 3 limited
API (by defining `Py_LIMITED_API`). The Python 3 code (in `if_python3.c`
and `if_py_both.h`) would now handle this and switch to limited API
mode. Without it set, Vim will still use the full API as before so this
is an opt-in change.
The main difference is that `PyType_Object` is now an opaque struct that
we can't directly create "static types" out of, and we have to create
type objects as "heap types" instead. This is because the struct is not
stable and changes from version to version (e.g. 3.8 added a
`tp_vectorcall` field to it). I had to change all the types to be
allocated on the heap instead with just a pointer to them.
Other functions are also simply missing in limited API, or they are
introduced too late (e.g. `PyUnicode_AsUTF8AndSize` in 3.10) to it that
we need some other ways to do the same thing, so I had to abstract a few
things into macros, and sometimes re-implement functions like
`PyObject_NEW`.
One caveat is that in limited API, `OutputType` (used for replacing
`sys.stdout`) no longer inherits from `PyStdPrinter_Type` which I don't
think has any real issue other than minor differences in how they
convert to a string and missing a couple functions like `mode()` and
`fileno()`.
Also fixed an existing bug where `tp_basicsize` was set incorrectly for
`BufferObject`, `TabListObject, `WinListObject`.
Technically, there could be a small performance drop, there is a little
more indirection with accessing type objects, and some APIs like
`PyUnicode_AsUTF8AndSize` are missing, but in practice I didn't see any
difference, and any well-written Python plugin should try to avoid
excessing callbacks to the `vim` module in Python anyway.
I only tested limited API mode down to Python 3.7, which seemes to
compile and work fine. I haven't tried earlier Python versions.
2) Fix PyIter_Check on older Python vers / type##Ptr unused warning
For PyIter_Check, older versions exposed them as either macros (used in
full API), or a function (for use in limited API). A previous change
exposed PyIter_Check to the dynamic build because Python just moved it
to function-only in 3.10 anyway. Because of that, just make sure we
always grab the function in dynamic builds in earlier versions since
that's what Python eventually did anyway.
3) Move Py_LIMITED_API define to configure script
Can now use --with-python-stable-abi flag to customize what stable ABI
version to target. Can also use an env var to do so as well.
4) Show +python/dyn-stable in :version, and allow has() feature query
Not sure if the "/dyn-stable" suffix would break things, or whether we
should do it another way. Or just don't show it in version and rely on
has() feature checking.
5) Documentation first draft. Still need to implement v:python3_version
6) Fix PyIter_Check build breaks when compiling against Python 3.8
7) Add CI coverage stable ABI on Linux/Windows / make configurable on Windows
This adds configurable options for Windows make files (both MinGW and
MSVC). CI will also now exercise both traditional full API and stable
ABI for Linux and Windows in the matrix for coverage.
Also added a "dynamic" option to Linux matrix as a drive-by change to
make other scripting languages like Ruby / Perl testable under both
static and dynamic builds.
8) Fix inaccuracy in Windows docs
Python's own docs are confusing but you don't actually want to use
`python3.dll` for the dynamic linkage.
9) Add generated autoconf file
10) Add v:python3_version support
This variable indicates the version of Python3 that Vim was built
against (PY_VERSION_HEX), and will be useful to check whether the Python
library you are loading in dynamically actually fits it. When built with
stable ABI, it will be the limited ABI version instead
(`Py_LIMITED_API`), which indicates the minimum version of Python 3 the
user should have, rather than the exact match. When stable ABI is used,
we won't be exposing PY_VERSION_HEX in this var because it just doesn't
seem necessary to do so (the whole point of stable ABI is the promise
that it will work across versions), and I don't want to confuse the user
with too many variables.
Also, cleaned up some documentation, and added help tags.
11) Fix Python 3.7 compat issues
Fix a couple issues when using limited API < 3.8
- Crash on exit: In Python 3.7, if a heap-allocated type is destroyed
before all instances are, it would cause a crash later. This happens
when we destroyed `OptionsType` before calling `Py_Finalize` when
using the limited API. To make it worse, later versions changed the
semantics and now each instance has a strong reference to its own type
and the recommendation has changed to have each instance de-ref its
own type and have its type in GC traversal. To avoid dealing with
these cross-version variations, we just don't free the heap type. They
are static types in non-limited-API anyway and are designed to last
through the entirety of the app, and we also don't restart the Python
runtime and therefore do not need it to have absolutely 0 leaks.
See:
- https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-c-api
- https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api
- PyIter_Check: This function is not provided in limited APIs older than
3.8. Previously I was trying to mock it out using manual
PyType_GetSlot() but it was brittle and also does not actually work
properly for static types (it will generate a Python error). Just
return false. It does mean using limited API < 3.8 is not recommended
as you lose the functionality to handle iterators, but from playing
with plugins I couldn't find it to be an issue.
- Fix loading of PyIter_Check so it will be done when limited API < 3.8.
Otherwise loading a 3.7 Python lib will fail even if limited API was
specified to use it.
12) Make sure to only load `PyUnicode_AsUTF8AndSize` in needed in limited API
We don't use this function unless limited API >= 3.10, but we were
loading it regardless. Usually it's ok in Unix-like systems where Python
just has a single lib that we load from, but in Windows where there is a
separate python3.dll this would not work as the symbol would not have
been exposed in this more limited DLL file. This makes it much clearer
under what condition is this function needed.
closes: #12032
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
2023-08-20 21:18:38 +02:00
|
|
|
# if (defined(USE_LIMITED_API) && Py_LIMITED_API >= 0x03080000) || \
|
|
|
|
(!defined(USE_LIMITED_API) && PY_VERSION_HEX >= 0x03080000)
|
|
|
|
# undef PyIter_Check
|
2021-06-14 15:08:30 +02:00
|
|
|
# define PyIter_Check py3_PyIter_Check
|
|
|
|
# endif
|
2012-06-29 12:54:53 +02:00
|
|
|
# define PyIter_Next py3_PyIter_Next
|
|
|
|
# define PyObject_GetIter py3_PyObject_GetIter
|
2013-06-23 14:16:57 +02:00
|
|
|
# define PyObject_Repr py3_PyObject_Repr
|
2013-05-30 13:22:13 +02:00
|
|
|
# define PyObject_GetItem py3_PyObject_GetItem
|
2013-05-15 14:51:35 +02:00
|
|
|
# define PyObject_IsTrue py3_PyObject_IsTrue
|
2010-07-17 21:19:38 +02:00
|
|
|
# define PyModule_GetDict py3_PyModule_GetDict
|
2024-09-10 20:56:13 +02:00
|
|
|
# if defined(USE_LIMITED_API) || PY_VERSION_HEX >= 0x03080000
|
2024-09-09 19:55:24 +02:00
|
|
|
# define Py_IncRef py3_Py_IncRef
|
|
|
|
# define Py_DecRef py3_Py_DecRef
|
2024-08-10 09:44:20 +02:00
|
|
|
# endif
|
2023-10-11 21:27:06 +02:00
|
|
|
# ifdef USE_LIMITED_API
|
|
|
|
# define Py_CompileString py3_Py_CompileString
|
|
|
|
# define PyEval_EvalCode py3_PyEval_EvalCode
|
|
|
|
# else
|
patch 9.0.1776: No support for stable Python 3 ABI
Problem: No support for stable Python 3 ABI
Solution: Support Python 3 stable ABI
Commits:
1) Support Python 3 stable ABI to allow mixed version interoperatbility
Vim currently supports embedding Python for use with plugins, and the
"dynamic" linking option allows the user to specify a locally installed
version of Python by setting `pythonthreedll`. However, one caveat is
that the Python 3 libs are not binary compatible across minor versions,
and mixing versions can potentially be dangerous (e.g. let's say Vim was
linked against the Python 3.10 SDK, but the user sets `pythonthreedll`
to a 3.11 lib). Usually, nothing bad happens, but in theory this could
lead to crashes, memory corruption, and other unpredictable behaviors.
It's also difficult for the user to tell something is wrong because Vim
has no way of reporting what Python 3 version Vim was linked with.
For Vim installed via a package manager, this usually isn't an issue
because all the dependencies would already be figured out. For prebuilt
Vim binaries like MacVim (my motivation for working on this), AppImage,
and Win32 installer this could potentially be an issue as usually a
single binary is distributed. This is more tricky when a new Python
version is released, as there's a chicken-and-egg issue with deciding
what Python version to build against and hard to keep in sync when a new
Python version just drops and we have a mix of users of different Python
versions, and a user just blindly upgrading to a new Python could lead to
bad interactions with Vim.
Python 3 does have a solution for this problem: stable ABI / limited API
(see https://docs.python.org/3/c-api/stable.html). The C SDK limits the
API to a set of functions that are promised to be stable across
versions. This pull request adds an ifdef config that allows us to turn
it on when building Vim. Vim binaries built with this option should be
safe to freely link with any Python 3 libraies without having the
constraint of having to use the same minor version.
Note: Python 2 has no such concept and this doesn't change how Python 2
integration works (not that there is going to be a new version of Python
2 that would cause compatibility issues in the future anyway).
---
Technical details:
======
The stable ABI can be accessed when we compile with the Python 3 limited
API (by defining `Py_LIMITED_API`). The Python 3 code (in `if_python3.c`
and `if_py_both.h`) would now handle this and switch to limited API
mode. Without it set, Vim will still use the full API as before so this
is an opt-in change.
The main difference is that `PyType_Object` is now an opaque struct that
we can't directly create "static types" out of, and we have to create
type objects as "heap types" instead. This is because the struct is not
stable and changes from version to version (e.g. 3.8 added a
`tp_vectorcall` field to it). I had to change all the types to be
allocated on the heap instead with just a pointer to them.
Other functions are also simply missing in limited API, or they are
introduced too late (e.g. `PyUnicode_AsUTF8AndSize` in 3.10) to it that
we need some other ways to do the same thing, so I had to abstract a few
things into macros, and sometimes re-implement functions like
`PyObject_NEW`.
One caveat is that in limited API, `OutputType` (used for replacing
`sys.stdout`) no longer inherits from `PyStdPrinter_Type` which I don't
think has any real issue other than minor differences in how they
convert to a string and missing a couple functions like `mode()` and
`fileno()`.
Also fixed an existing bug where `tp_basicsize` was set incorrectly for
`BufferObject`, `TabListObject, `WinListObject`.
Technically, there could be a small performance drop, there is a little
more indirection with accessing type objects, and some APIs like
`PyUnicode_AsUTF8AndSize` are missing, but in practice I didn't see any
difference, and any well-written Python plugin should try to avoid
excessing callbacks to the `vim` module in Python anyway.
I only tested limited API mode down to Python 3.7, which seemes to
compile and work fine. I haven't tried earlier Python versions.
2) Fix PyIter_Check on older Python vers / type##Ptr unused warning
For PyIter_Check, older versions exposed them as either macros (used in
full API), or a function (for use in limited API). A previous change
exposed PyIter_Check to the dynamic build because Python just moved it
to function-only in 3.10 anyway. Because of that, just make sure we
always grab the function in dynamic builds in earlier versions since
that's what Python eventually did anyway.
3) Move Py_LIMITED_API define to configure script
Can now use --with-python-stable-abi flag to customize what stable ABI
version to target. Can also use an env var to do so as well.
4) Show +python/dyn-stable in :version, and allow has() feature query
Not sure if the "/dyn-stable" suffix would break things, or whether we
should do it another way. Or just don't show it in version and rely on
has() feature checking.
5) Documentation first draft. Still need to implement v:python3_version
6) Fix PyIter_Check build breaks when compiling against Python 3.8
7) Add CI coverage stable ABI on Linux/Windows / make configurable on Windows
This adds configurable options for Windows make files (both MinGW and
MSVC). CI will also now exercise both traditional full API and stable
ABI for Linux and Windows in the matrix for coverage.
Also added a "dynamic" option to Linux matrix as a drive-by change to
make other scripting languages like Ruby / Perl testable under both
static and dynamic builds.
8) Fix inaccuracy in Windows docs
Python's own docs are confusing but you don't actually want to use
`python3.dll` for the dynamic linkage.
9) Add generated autoconf file
10) Add v:python3_version support
This variable indicates the version of Python3 that Vim was built
against (PY_VERSION_HEX), and will be useful to check whether the Python
library you are loading in dynamically actually fits it. When built with
stable ABI, it will be the limited ABI version instead
(`Py_LIMITED_API`), which indicates the minimum version of Python 3 the
user should have, rather than the exact match. When stable ABI is used,
we won't be exposing PY_VERSION_HEX in this var because it just doesn't
seem necessary to do so (the whole point of stable ABI is the promise
that it will work across versions), and I don't want to confuse the user
with too many variables.
Also, cleaned up some documentation, and added help tags.
11) Fix Python 3.7 compat issues
Fix a couple issues when using limited API < 3.8
- Crash on exit: In Python 3.7, if a heap-allocated type is destroyed
before all instances are, it would cause a crash later. This happens
when we destroyed `OptionsType` before calling `Py_Finalize` when
using the limited API. To make it worse, later versions changed the
semantics and now each instance has a strong reference to its own type
and the recommendation has changed to have each instance de-ref its
own type and have its type in GC traversal. To avoid dealing with
these cross-version variations, we just don't free the heap type. They
are static types in non-limited-API anyway and are designed to last
through the entirety of the app, and we also don't restart the Python
runtime and therefore do not need it to have absolutely 0 leaks.
See:
- https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-c-api
- https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api
- PyIter_Check: This function is not provided in limited APIs older than
3.8. Previously I was trying to mock it out using manual
PyType_GetSlot() but it was brittle and also does not actually work
properly for static types (it will generate a Python error). Just
return false. It does mean using limited API < 3.8 is not recommended
as you lose the functionality to handle iterators, but from playing
with plugins I couldn't find it to be an issue.
- Fix loading of PyIter_Check so it will be done when limited API < 3.8.
Otherwise loading a 3.7 Python lib will fail even if limited API was
specified to use it.
12) Make sure to only load `PyUnicode_AsUTF8AndSize` in needed in limited API
We don't use this function unless limited API >= 3.10, but we were
loading it regardless. Usually it's ok in Unix-like systems where Python
just has a single lib that we load from, but in Windows where there is a
separate python3.dll this would not work as the symbol would not have
been exposed in this more limited DLL file. This makes it much clearer
under what condition is this function needed.
closes: #12032
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
2023-08-20 21:18:38 +02:00
|
|
|
# undef PyRun_SimpleString
|
|
|
|
# define PyRun_SimpleString py3_PyRun_SimpleString
|
|
|
|
# undef PyRun_String
|
|
|
|
# define PyRun_String py3_PyRun_String
|
|
|
|
# endif
|
2013-05-15 18:28:13 +02:00
|
|
|
# define PyObject_GetAttrString py3_PyObject_GetAttrString
|
2013-05-30 13:01:18 +02:00
|
|
|
# define PyObject_HasAttrString py3_PyObject_HasAttrString
|
2013-05-15 18:28:13 +02:00
|
|
|
# define PyObject_SetAttrString py3_PyObject_SetAttrString
|
|
|
|
# define PyObject_CallFunctionObjArgs py3_PyObject_CallFunctionObjArgs
|
2024-07-04 16:36:05 +02:00
|
|
|
# if PY_VERSION_HEX >= 0x030d0000
|
|
|
|
# define PyObject_CallFunction py3_PyObject_CallFunction
|
|
|
|
# else
|
|
|
|
# define _PyObject_CallFunction_SizeT py3__PyObject_CallFunction_SizeT
|
|
|
|
# endif
|
2013-06-02 18:20:17 +02:00
|
|
|
# define PyObject_Call py3_PyObject_Call
|
2013-05-15 18:28:13 +02:00
|
|
|
# define PyEval_GetLocals py3_PyEval_GetLocals
|
|
|
|
# define PyEval_GetGlobals py3_PyEval_GetGlobals
|
2010-07-17 21:19:38 +02:00
|
|
|
# define PySys_SetObject py3_PySys_SetObject
|
2013-06-10 21:27:29 +02:00
|
|
|
# define PySys_GetObject py3_PySys_GetObject
|
2010-07-17 21:19:38 +02:00
|
|
|
# define PySys_SetArgv py3_PySys_SetArgv
|
|
|
|
# define PyType_Ready py3_PyType_Ready
|
patch 9.0.1776: No support for stable Python 3 ABI
Problem: No support for stable Python 3 ABI
Solution: Support Python 3 stable ABI
Commits:
1) Support Python 3 stable ABI to allow mixed version interoperatbility
Vim currently supports embedding Python for use with plugins, and the
"dynamic" linking option allows the user to specify a locally installed
version of Python by setting `pythonthreedll`. However, one caveat is
that the Python 3 libs are not binary compatible across minor versions,
and mixing versions can potentially be dangerous (e.g. let's say Vim was
linked against the Python 3.10 SDK, but the user sets `pythonthreedll`
to a 3.11 lib). Usually, nothing bad happens, but in theory this could
lead to crashes, memory corruption, and other unpredictable behaviors.
It's also difficult for the user to tell something is wrong because Vim
has no way of reporting what Python 3 version Vim was linked with.
For Vim installed via a package manager, this usually isn't an issue
because all the dependencies would already be figured out. For prebuilt
Vim binaries like MacVim (my motivation for working on this), AppImage,
and Win32 installer this could potentially be an issue as usually a
single binary is distributed. This is more tricky when a new Python
version is released, as there's a chicken-and-egg issue with deciding
what Python version to build against and hard to keep in sync when a new
Python version just drops and we have a mix of users of different Python
versions, and a user just blindly upgrading to a new Python could lead to
bad interactions with Vim.
Python 3 does have a solution for this problem: stable ABI / limited API
(see https://docs.python.org/3/c-api/stable.html). The C SDK limits the
API to a set of functions that are promised to be stable across
versions. This pull request adds an ifdef config that allows us to turn
it on when building Vim. Vim binaries built with this option should be
safe to freely link with any Python 3 libraies without having the
constraint of having to use the same minor version.
Note: Python 2 has no such concept and this doesn't change how Python 2
integration works (not that there is going to be a new version of Python
2 that would cause compatibility issues in the future anyway).
---
Technical details:
======
The stable ABI can be accessed when we compile with the Python 3 limited
API (by defining `Py_LIMITED_API`). The Python 3 code (in `if_python3.c`
and `if_py_both.h`) would now handle this and switch to limited API
mode. Without it set, Vim will still use the full API as before so this
is an opt-in change.
The main difference is that `PyType_Object` is now an opaque struct that
we can't directly create "static types" out of, and we have to create
type objects as "heap types" instead. This is because the struct is not
stable and changes from version to version (e.g. 3.8 added a
`tp_vectorcall` field to it). I had to change all the types to be
allocated on the heap instead with just a pointer to them.
Other functions are also simply missing in limited API, or they are
introduced too late (e.g. `PyUnicode_AsUTF8AndSize` in 3.10) to it that
we need some other ways to do the same thing, so I had to abstract a few
things into macros, and sometimes re-implement functions like
`PyObject_NEW`.
One caveat is that in limited API, `OutputType` (used for replacing
`sys.stdout`) no longer inherits from `PyStdPrinter_Type` which I don't
think has any real issue other than minor differences in how they
convert to a string and missing a couple functions like `mode()` and
`fileno()`.
Also fixed an existing bug where `tp_basicsize` was set incorrectly for
`BufferObject`, `TabListObject, `WinListObject`.
Technically, there could be a small performance drop, there is a little
more indirection with accessing type objects, and some APIs like
`PyUnicode_AsUTF8AndSize` are missing, but in practice I didn't see any
difference, and any well-written Python plugin should try to avoid
excessing callbacks to the `vim` module in Python anyway.
I only tested limited API mode down to Python 3.7, which seemes to
compile and work fine. I haven't tried earlier Python versions.
2) Fix PyIter_Check on older Python vers / type##Ptr unused warning
For PyIter_Check, older versions exposed them as either macros (used in
full API), or a function (for use in limited API). A previous change
exposed PyIter_Check to the dynamic build because Python just moved it
to function-only in 3.10 anyway. Because of that, just make sure we
always grab the function in dynamic builds in earlier versions since
that's what Python eventually did anyway.
3) Move Py_LIMITED_API define to configure script
Can now use --with-python-stable-abi flag to customize what stable ABI
version to target. Can also use an env var to do so as well.
4) Show +python/dyn-stable in :version, and allow has() feature query
Not sure if the "/dyn-stable" suffix would break things, or whether we
should do it another way. Or just don't show it in version and rely on
has() feature checking.
5) Documentation first draft. Still need to implement v:python3_version
6) Fix PyIter_Check build breaks when compiling against Python 3.8
7) Add CI coverage stable ABI on Linux/Windows / make configurable on Windows
This adds configurable options for Windows make files (both MinGW and
MSVC). CI will also now exercise both traditional full API and stable
ABI for Linux and Windows in the matrix for coverage.
Also added a "dynamic" option to Linux matrix as a drive-by change to
make other scripting languages like Ruby / Perl testable under both
static and dynamic builds.
8) Fix inaccuracy in Windows docs
Python's own docs are confusing but you don't actually want to use
`python3.dll` for the dynamic linkage.
9) Add generated autoconf file
10) Add v:python3_version support
This variable indicates the version of Python3 that Vim was built
against (PY_VERSION_HEX), and will be useful to check whether the Python
library you are loading in dynamically actually fits it. When built with
stable ABI, it will be the limited ABI version instead
(`Py_LIMITED_API`), which indicates the minimum version of Python 3 the
user should have, rather than the exact match. When stable ABI is used,
we won't be exposing PY_VERSION_HEX in this var because it just doesn't
seem necessary to do so (the whole point of stable ABI is the promise
that it will work across versions), and I don't want to confuse the user
with too many variables.
Also, cleaned up some documentation, and added help tags.
11) Fix Python 3.7 compat issues
Fix a couple issues when using limited API < 3.8
- Crash on exit: In Python 3.7, if a heap-allocated type is destroyed
before all instances are, it would cause a crash later. This happens
when we destroyed `OptionsType` before calling `Py_Finalize` when
using the limited API. To make it worse, later versions changed the
semantics and now each instance has a strong reference to its own type
and the recommendation has changed to have each instance de-ref its
own type and have its type in GC traversal. To avoid dealing with
these cross-version variations, we just don't free the heap type. They
are static types in non-limited-API anyway and are designed to last
through the entirety of the app, and we also don't restart the Python
runtime and therefore do not need it to have absolutely 0 leaks.
See:
- https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-c-api
- https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api
- PyIter_Check: This function is not provided in limited APIs older than
3.8. Previously I was trying to mock it out using manual
PyType_GetSlot() but it was brittle and also does not actually work
properly for static types (it will generate a Python error). Just
return false. It does mean using limited API < 3.8 is not recommended
as you lose the functionality to handle iterators, but from playing
with plugins I couldn't find it to be an issue.
- Fix loading of PyIter_Check so it will be done when limited API < 3.8.
Otherwise loading a 3.7 Python lib will fail even if limited API was
specified to use it.
12) Make sure to only load `PyUnicode_AsUTF8AndSize` in needed in limited API
We don't use this function unless limited API >= 3.10, but we were
loading it regardless. Usually it's ok in Unix-like systems where Python
just has a single lib that we load from, but in Windows where there is a
separate python3.dll this would not work as the symbol would not have
been exposed in this more limited DLL file. This makes it much clearer
under what condition is this function needed.
closes: #12032
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
2023-08-20 21:18:38 +02:00
|
|
|
# if PY_VERSION_HEX >= 0x03040000
|
2020-07-16 22:15:53 +02:00
|
|
|
# define PyType_GetFlags py3_PyType_GetFlags
|
|
|
|
# endif
|
2023-10-04 20:05:05 +02:00
|
|
|
# undef Py_BuildValue
|
2010-07-17 21:19:38 +02:00
|
|
|
# define Py_BuildValue py3_Py_BuildValue
|
2010-11-16 19:26:02 +01:00
|
|
|
# define Py_SetPythonHome py3_Py_SetPythonHome
|
2010-07-17 21:19:38 +02:00
|
|
|
# define Py_Initialize py3_Py_Initialize
|
|
|
|
# define Py_Finalize py3_Py_Finalize
|
|
|
|
# define Py_IsInitialized py3_Py_IsInitialized
|
|
|
|
# define _Py_NoneStruct (*py3__Py_NoneStruct)
|
2012-09-21 14:00:35 +02:00
|
|
|
# define _Py_FalseStruct (*py3__Py_FalseStruct)
|
|
|
|
# define _Py_TrueStruct (*py3__Py_TrueStruct)
|
2024-09-09 19:46:17 +02:00
|
|
|
# if !defined(USE_LIMITED_API) && PY_VERSION_HEX < 0x030D0000
|
|
|
|
// Private symbol that used to be required as part of PyIter_Check.
|
2023-10-04 20:05:05 +02:00
|
|
|
# define _PyObject_NextNotImplemented (*py3__PyObject_NextNotImplemented)
|
|
|
|
# endif
|
2010-07-17 21:19:38 +02:00
|
|
|
# define PyModule_AddObject py3_PyModule_AddObject
|
|
|
|
# define PyImport_AppendInittab py3_PyImport_AppendInittab
|
2013-05-15 18:28:13 +02:00
|
|
|
# define PyImport_AddModule py3_PyImport_AddModule
|
patch 9.0.1776: No support for stable Python 3 ABI
Problem: No support for stable Python 3 ABI
Solution: Support Python 3 stable ABI
Commits:
1) Support Python 3 stable ABI to allow mixed version interoperatbility
Vim currently supports embedding Python for use with plugins, and the
"dynamic" linking option allows the user to specify a locally installed
version of Python by setting `pythonthreedll`. However, one caveat is
that the Python 3 libs are not binary compatible across minor versions,
and mixing versions can potentially be dangerous (e.g. let's say Vim was
linked against the Python 3.10 SDK, but the user sets `pythonthreedll`
to a 3.11 lib). Usually, nothing bad happens, but in theory this could
lead to crashes, memory corruption, and other unpredictable behaviors.
It's also difficult for the user to tell something is wrong because Vim
has no way of reporting what Python 3 version Vim was linked with.
For Vim installed via a package manager, this usually isn't an issue
because all the dependencies would already be figured out. For prebuilt
Vim binaries like MacVim (my motivation for working on this), AppImage,
and Win32 installer this could potentially be an issue as usually a
single binary is distributed. This is more tricky when a new Python
version is released, as there's a chicken-and-egg issue with deciding
what Python version to build against and hard to keep in sync when a new
Python version just drops and we have a mix of users of different Python
versions, and a user just blindly upgrading to a new Python could lead to
bad interactions with Vim.
Python 3 does have a solution for this problem: stable ABI / limited API
(see https://docs.python.org/3/c-api/stable.html). The C SDK limits the
API to a set of functions that are promised to be stable across
versions. This pull request adds an ifdef config that allows us to turn
it on when building Vim. Vim binaries built with this option should be
safe to freely link with any Python 3 libraies without having the
constraint of having to use the same minor version.
Note: Python 2 has no such concept and this doesn't change how Python 2
integration works (not that there is going to be a new version of Python
2 that would cause compatibility issues in the future anyway).
---
Technical details:
======
The stable ABI can be accessed when we compile with the Python 3 limited
API (by defining `Py_LIMITED_API`). The Python 3 code (in `if_python3.c`
and `if_py_both.h`) would now handle this and switch to limited API
mode. Without it set, Vim will still use the full API as before so this
is an opt-in change.
The main difference is that `PyType_Object` is now an opaque struct that
we can't directly create "static types" out of, and we have to create
type objects as "heap types" instead. This is because the struct is not
stable and changes from version to version (e.g. 3.8 added a
`tp_vectorcall` field to it). I had to change all the types to be
allocated on the heap instead with just a pointer to them.
Other functions are also simply missing in limited API, or they are
introduced too late (e.g. `PyUnicode_AsUTF8AndSize` in 3.10) to it that
we need some other ways to do the same thing, so I had to abstract a few
things into macros, and sometimes re-implement functions like
`PyObject_NEW`.
One caveat is that in limited API, `OutputType` (used for replacing
`sys.stdout`) no longer inherits from `PyStdPrinter_Type` which I don't
think has any real issue other than minor differences in how they
convert to a string and missing a couple functions like `mode()` and
`fileno()`.
Also fixed an existing bug where `tp_basicsize` was set incorrectly for
`BufferObject`, `TabListObject, `WinListObject`.
Technically, there could be a small performance drop, there is a little
more indirection with accessing type objects, and some APIs like
`PyUnicode_AsUTF8AndSize` are missing, but in practice I didn't see any
difference, and any well-written Python plugin should try to avoid
excessing callbacks to the `vim` module in Python anyway.
I only tested limited API mode down to Python 3.7, which seemes to
compile and work fine. I haven't tried earlier Python versions.
2) Fix PyIter_Check on older Python vers / type##Ptr unused warning
For PyIter_Check, older versions exposed them as either macros (used in
full API), or a function (for use in limited API). A previous change
exposed PyIter_Check to the dynamic build because Python just moved it
to function-only in 3.10 anyway. Because of that, just make sure we
always grab the function in dynamic builds in earlier versions since
that's what Python eventually did anyway.
3) Move Py_LIMITED_API define to configure script
Can now use --with-python-stable-abi flag to customize what stable ABI
version to target. Can also use an env var to do so as well.
4) Show +python/dyn-stable in :version, and allow has() feature query
Not sure if the "/dyn-stable" suffix would break things, or whether we
should do it another way. Or just don't show it in version and rely on
has() feature checking.
5) Documentation first draft. Still need to implement v:python3_version
6) Fix PyIter_Check build breaks when compiling against Python 3.8
7) Add CI coverage stable ABI on Linux/Windows / make configurable on Windows
This adds configurable options for Windows make files (both MinGW and
MSVC). CI will also now exercise both traditional full API and stable
ABI for Linux and Windows in the matrix for coverage.
Also added a "dynamic" option to Linux matrix as a drive-by change to
make other scripting languages like Ruby / Perl testable under both
static and dynamic builds.
8) Fix inaccuracy in Windows docs
Python's own docs are confusing but you don't actually want to use
`python3.dll` for the dynamic linkage.
9) Add generated autoconf file
10) Add v:python3_version support
This variable indicates the version of Python3 that Vim was built
against (PY_VERSION_HEX), and will be useful to check whether the Python
library you are loading in dynamically actually fits it. When built with
stable ABI, it will be the limited ABI version instead
(`Py_LIMITED_API`), which indicates the minimum version of Python 3 the
user should have, rather than the exact match. When stable ABI is used,
we won't be exposing PY_VERSION_HEX in this var because it just doesn't
seem necessary to do so (the whole point of stable ABI is the promise
that it will work across versions), and I don't want to confuse the user
with too many variables.
Also, cleaned up some documentation, and added help tags.
11) Fix Python 3.7 compat issues
Fix a couple issues when using limited API < 3.8
- Crash on exit: In Python 3.7, if a heap-allocated type is destroyed
before all instances are, it would cause a crash later. This happens
when we destroyed `OptionsType` before calling `Py_Finalize` when
using the limited API. To make it worse, later versions changed the
semantics and now each instance has a strong reference to its own type
and the recommendation has changed to have each instance de-ref its
own type and have its type in GC traversal. To avoid dealing with
these cross-version variations, we just don't free the heap type. They
are static types in non-limited-API anyway and are designed to last
through the entirety of the app, and we also don't restart the Python
runtime and therefore do not need it to have absolutely 0 leaks.
See:
- https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-c-api
- https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api
- PyIter_Check: This function is not provided in limited APIs older than
3.8. Previously I was trying to mock it out using manual
PyType_GetSlot() but it was brittle and also does not actually work
properly for static types (it will generate a Python error). Just
return false. It does mean using limited API < 3.8 is not recommended
as you lose the functionality to handle iterators, but from playing
with plugins I couldn't find it to be an issue.
- Fix loading of PyIter_Check so it will be done when limited API < 3.8.
Otherwise loading a 3.7 Python lib will fail even if limited API was
specified to use it.
12) Make sure to only load `PyUnicode_AsUTF8AndSize` in needed in limited API
We don't use this function unless limited API >= 3.10, but we were
loading it regardless. Usually it's ok in Unix-like systems where Python
just has a single lib that we load from, but in Windows where there is a
separate python3.dll this would not work as the symbol would not have
been exposed in this more limited DLL file. This makes it much clearer
under what condition is this function needed.
closes: #12032
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
2023-08-20 21:18:38 +02:00
|
|
|
# ifdef USE_LIMITED_API
|
|
|
|
# if Py_LIMITED_API >= 0x030a0000
|
|
|
|
# define PyUnicode_AsUTF8AndSize py3_PyUnicode_AsUTF8AndSize
|
|
|
|
# endif
|
2012-10-14 03:22:56 +02:00
|
|
|
# else
|
patch 9.0.1776: No support for stable Python 3 ABI
Problem: No support for stable Python 3 ABI
Solution: Support Python 3 stable ABI
Commits:
1) Support Python 3 stable ABI to allow mixed version interoperatbility
Vim currently supports embedding Python for use with plugins, and the
"dynamic" linking option allows the user to specify a locally installed
version of Python by setting `pythonthreedll`. However, one caveat is
that the Python 3 libs are not binary compatible across minor versions,
and mixing versions can potentially be dangerous (e.g. let's say Vim was
linked against the Python 3.10 SDK, but the user sets `pythonthreedll`
to a 3.11 lib). Usually, nothing bad happens, but in theory this could
lead to crashes, memory corruption, and other unpredictable behaviors.
It's also difficult for the user to tell something is wrong because Vim
has no way of reporting what Python 3 version Vim was linked with.
For Vim installed via a package manager, this usually isn't an issue
because all the dependencies would already be figured out. For prebuilt
Vim binaries like MacVim (my motivation for working on this), AppImage,
and Win32 installer this could potentially be an issue as usually a
single binary is distributed. This is more tricky when a new Python
version is released, as there's a chicken-and-egg issue with deciding
what Python version to build against and hard to keep in sync when a new
Python version just drops and we have a mix of users of different Python
versions, and a user just blindly upgrading to a new Python could lead to
bad interactions with Vim.
Python 3 does have a solution for this problem: stable ABI / limited API
(see https://docs.python.org/3/c-api/stable.html). The C SDK limits the
API to a set of functions that are promised to be stable across
versions. This pull request adds an ifdef config that allows us to turn
it on when building Vim. Vim binaries built with this option should be
safe to freely link with any Python 3 libraies without having the
constraint of having to use the same minor version.
Note: Python 2 has no such concept and this doesn't change how Python 2
integration works (not that there is going to be a new version of Python
2 that would cause compatibility issues in the future anyway).
---
Technical details:
======
The stable ABI can be accessed when we compile with the Python 3 limited
API (by defining `Py_LIMITED_API`). The Python 3 code (in `if_python3.c`
and `if_py_both.h`) would now handle this and switch to limited API
mode. Without it set, Vim will still use the full API as before so this
is an opt-in change.
The main difference is that `PyType_Object` is now an opaque struct that
we can't directly create "static types" out of, and we have to create
type objects as "heap types" instead. This is because the struct is not
stable and changes from version to version (e.g. 3.8 added a
`tp_vectorcall` field to it). I had to change all the types to be
allocated on the heap instead with just a pointer to them.
Other functions are also simply missing in limited API, or they are
introduced too late (e.g. `PyUnicode_AsUTF8AndSize` in 3.10) to it that
we need some other ways to do the same thing, so I had to abstract a few
things into macros, and sometimes re-implement functions like
`PyObject_NEW`.
One caveat is that in limited API, `OutputType` (used for replacing
`sys.stdout`) no longer inherits from `PyStdPrinter_Type` which I don't
think has any real issue other than minor differences in how they
convert to a string and missing a couple functions like `mode()` and
`fileno()`.
Also fixed an existing bug where `tp_basicsize` was set incorrectly for
`BufferObject`, `TabListObject, `WinListObject`.
Technically, there could be a small performance drop, there is a little
more indirection with accessing type objects, and some APIs like
`PyUnicode_AsUTF8AndSize` are missing, but in practice I didn't see any
difference, and any well-written Python plugin should try to avoid
excessing callbacks to the `vim` module in Python anyway.
I only tested limited API mode down to Python 3.7, which seemes to
compile and work fine. I haven't tried earlier Python versions.
2) Fix PyIter_Check on older Python vers / type##Ptr unused warning
For PyIter_Check, older versions exposed them as either macros (used in
full API), or a function (for use in limited API). A previous change
exposed PyIter_Check to the dynamic build because Python just moved it
to function-only in 3.10 anyway. Because of that, just make sure we
always grab the function in dynamic builds in earlier versions since
that's what Python eventually did anyway.
3) Move Py_LIMITED_API define to configure script
Can now use --with-python-stable-abi flag to customize what stable ABI
version to target. Can also use an env var to do so as well.
4) Show +python/dyn-stable in :version, and allow has() feature query
Not sure if the "/dyn-stable" suffix would break things, or whether we
should do it another way. Or just don't show it in version and rely on
has() feature checking.
5) Documentation first draft. Still need to implement v:python3_version
6) Fix PyIter_Check build breaks when compiling against Python 3.8
7) Add CI coverage stable ABI on Linux/Windows / make configurable on Windows
This adds configurable options for Windows make files (both MinGW and
MSVC). CI will also now exercise both traditional full API and stable
ABI for Linux and Windows in the matrix for coverage.
Also added a "dynamic" option to Linux matrix as a drive-by change to
make other scripting languages like Ruby / Perl testable under both
static and dynamic builds.
8) Fix inaccuracy in Windows docs
Python's own docs are confusing but you don't actually want to use
`python3.dll` for the dynamic linkage.
9) Add generated autoconf file
10) Add v:python3_version support
This variable indicates the version of Python3 that Vim was built
against (PY_VERSION_HEX), and will be useful to check whether the Python
library you are loading in dynamically actually fits it. When built with
stable ABI, it will be the limited ABI version instead
(`Py_LIMITED_API`), which indicates the minimum version of Python 3 the
user should have, rather than the exact match. When stable ABI is used,
we won't be exposing PY_VERSION_HEX in this var because it just doesn't
seem necessary to do so (the whole point of stable ABI is the promise
that it will work across versions), and I don't want to confuse the user
with too many variables.
Also, cleaned up some documentation, and added help tags.
11) Fix Python 3.7 compat issues
Fix a couple issues when using limited API < 3.8
- Crash on exit: In Python 3.7, if a heap-allocated type is destroyed
before all instances are, it would cause a crash later. This happens
when we destroyed `OptionsType` before calling `Py_Finalize` when
using the limited API. To make it worse, later versions changed the
semantics and now each instance has a strong reference to its own type
and the recommendation has changed to have each instance de-ref its
own type and have its type in GC traversal. To avoid dealing with
these cross-version variations, we just don't free the heap type. They
are static types in non-limited-API anyway and are designed to last
through the entirety of the app, and we also don't restart the Python
runtime and therefore do not need it to have absolutely 0 leaks.
See:
- https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-c-api
- https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api
- PyIter_Check: This function is not provided in limited APIs older than
3.8. Previously I was trying to mock it out using manual
PyType_GetSlot() but it was brittle and also does not actually work
properly for static types (it will generate a Python error). Just
return false. It does mean using limited API < 3.8 is not recommended
as you lose the functionality to handle iterators, but from playing
with plugins I couldn't find it to be an issue.
- Fix loading of PyIter_Check so it will be done when limited API < 3.8.
Otherwise loading a 3.7 Python lib will fail even if limited API was
specified to use it.
12) Make sure to only load `PyUnicode_AsUTF8AndSize` in needed in limited API
We don't use this function unless limited API >= 3.10, but we were
loading it regardless. Usually it's ok in Unix-like systems where Python
just has a single lib that we load from, but in Windows where there is a
separate python3.dll this would not work as the symbol would not have
been exposed in this more limited DLL file. This makes it much clearer
under what condition is this function needed.
closes: #12032
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
2023-08-20 21:18:38 +02:00
|
|
|
# if PY_VERSION_HEX >= 0x030300f0
|
|
|
|
# define PyUnicode_AsUTF8AndSize py3_PyUnicode_AsUTF8AndSize
|
|
|
|
# else
|
|
|
|
# define _PyUnicode_AsString py3__PyUnicode_AsString
|
|
|
|
# endif
|
2012-10-14 03:22:56 +02:00
|
|
|
# endif
|
patch 9.0.1776: No support for stable Python 3 ABI
Problem: No support for stable Python 3 ABI
Solution: Support Python 3 stable ABI
Commits:
1) Support Python 3 stable ABI to allow mixed version interoperatbility
Vim currently supports embedding Python for use with plugins, and the
"dynamic" linking option allows the user to specify a locally installed
version of Python by setting `pythonthreedll`. However, one caveat is
that the Python 3 libs are not binary compatible across minor versions,
and mixing versions can potentially be dangerous (e.g. let's say Vim was
linked against the Python 3.10 SDK, but the user sets `pythonthreedll`
to a 3.11 lib). Usually, nothing bad happens, but in theory this could
lead to crashes, memory corruption, and other unpredictable behaviors.
It's also difficult for the user to tell something is wrong because Vim
has no way of reporting what Python 3 version Vim was linked with.
For Vim installed via a package manager, this usually isn't an issue
because all the dependencies would already be figured out. For prebuilt
Vim binaries like MacVim (my motivation for working on this), AppImage,
and Win32 installer this could potentially be an issue as usually a
single binary is distributed. This is more tricky when a new Python
version is released, as there's a chicken-and-egg issue with deciding
what Python version to build against and hard to keep in sync when a new
Python version just drops and we have a mix of users of different Python
versions, and a user just blindly upgrading to a new Python could lead to
bad interactions with Vim.
Python 3 does have a solution for this problem: stable ABI / limited API
(see https://docs.python.org/3/c-api/stable.html). The C SDK limits the
API to a set of functions that are promised to be stable across
versions. This pull request adds an ifdef config that allows us to turn
it on when building Vim. Vim binaries built with this option should be
safe to freely link with any Python 3 libraies without having the
constraint of having to use the same minor version.
Note: Python 2 has no such concept and this doesn't change how Python 2
integration works (not that there is going to be a new version of Python
2 that would cause compatibility issues in the future anyway).
---
Technical details:
======
The stable ABI can be accessed when we compile with the Python 3 limited
API (by defining `Py_LIMITED_API`). The Python 3 code (in `if_python3.c`
and `if_py_both.h`) would now handle this and switch to limited API
mode. Without it set, Vim will still use the full API as before so this
is an opt-in change.
The main difference is that `PyType_Object` is now an opaque struct that
we can't directly create "static types" out of, and we have to create
type objects as "heap types" instead. This is because the struct is not
stable and changes from version to version (e.g. 3.8 added a
`tp_vectorcall` field to it). I had to change all the types to be
allocated on the heap instead with just a pointer to them.
Other functions are also simply missing in limited API, or they are
introduced too late (e.g. `PyUnicode_AsUTF8AndSize` in 3.10) to it that
we need some other ways to do the same thing, so I had to abstract a few
things into macros, and sometimes re-implement functions like
`PyObject_NEW`.
One caveat is that in limited API, `OutputType` (used for replacing
`sys.stdout`) no longer inherits from `PyStdPrinter_Type` which I don't
think has any real issue other than minor differences in how they
convert to a string and missing a couple functions like `mode()` and
`fileno()`.
Also fixed an existing bug where `tp_basicsize` was set incorrectly for
`BufferObject`, `TabListObject, `WinListObject`.
Technically, there could be a small performance drop, there is a little
more indirection with accessing type objects, and some APIs like
`PyUnicode_AsUTF8AndSize` are missing, but in practice I didn't see any
difference, and any well-written Python plugin should try to avoid
excessing callbacks to the `vim` module in Python anyway.
I only tested limited API mode down to Python 3.7, which seemes to
compile and work fine. I haven't tried earlier Python versions.
2) Fix PyIter_Check on older Python vers / type##Ptr unused warning
For PyIter_Check, older versions exposed them as either macros (used in
full API), or a function (for use in limited API). A previous change
exposed PyIter_Check to the dynamic build because Python just moved it
to function-only in 3.10 anyway. Because of that, just make sure we
always grab the function in dynamic builds in earlier versions since
that's what Python eventually did anyway.
3) Move Py_LIMITED_API define to configure script
Can now use --with-python-stable-abi flag to customize what stable ABI
version to target. Can also use an env var to do so as well.
4) Show +python/dyn-stable in :version, and allow has() feature query
Not sure if the "/dyn-stable" suffix would break things, or whether we
should do it another way. Or just don't show it in version and rely on
has() feature checking.
5) Documentation first draft. Still need to implement v:python3_version
6) Fix PyIter_Check build breaks when compiling against Python 3.8
7) Add CI coverage stable ABI on Linux/Windows / make configurable on Windows
This adds configurable options for Windows make files (both MinGW and
MSVC). CI will also now exercise both traditional full API and stable
ABI for Linux and Windows in the matrix for coverage.
Also added a "dynamic" option to Linux matrix as a drive-by change to
make other scripting languages like Ruby / Perl testable under both
static and dynamic builds.
8) Fix inaccuracy in Windows docs
Python's own docs are confusing but you don't actually want to use
`python3.dll` for the dynamic linkage.
9) Add generated autoconf file
10) Add v:python3_version support
This variable indicates the version of Python3 that Vim was built
against (PY_VERSION_HEX), and will be useful to check whether the Python
library you are loading in dynamically actually fits it. When built with
stable ABI, it will be the limited ABI version instead
(`Py_LIMITED_API`), which indicates the minimum version of Python 3 the
user should have, rather than the exact match. When stable ABI is used,
we won't be exposing PY_VERSION_HEX in this var because it just doesn't
seem necessary to do so (the whole point of stable ABI is the promise
that it will work across versions), and I don't want to confuse the user
with too many variables.
Also, cleaned up some documentation, and added help tags.
11) Fix Python 3.7 compat issues
Fix a couple issues when using limited API < 3.8
- Crash on exit: In Python 3.7, if a heap-allocated type is destroyed
before all instances are, it would cause a crash later. This happens
when we destroyed `OptionsType` before calling `Py_Finalize` when
using the limited API. To make it worse, later versions changed the
semantics and now each instance has a strong reference to its own type
and the recommendation has changed to have each instance de-ref its
own type and have its type in GC traversal. To avoid dealing with
these cross-version variations, we just don't free the heap type. They
are static types in non-limited-API anyway and are designed to last
through the entirety of the app, and we also don't restart the Python
runtime and therefore do not need it to have absolutely 0 leaks.
See:
- https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-c-api
- https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api
- PyIter_Check: This function is not provided in limited APIs older than
3.8. Previously I was trying to mock it out using manual
PyType_GetSlot() but it was brittle and also does not actually work
properly for static types (it will generate a Python error). Just
return false. It does mean using limited API < 3.8 is not recommended
as you lose the functionality to handle iterators, but from playing
with plugins I couldn't find it to be an issue.
- Fix loading of PyIter_Check so it will be done when limited API < 3.8.
Otherwise loading a 3.7 Python lib will fail even if limited API was
specified to use it.
12) Make sure to only load `PyUnicode_AsUTF8AndSize` in needed in limited API
We don't use this function unless limited API >= 3.10, but we were
loading it regardless. Usually it's ok in Unix-like systems where Python
just has a single lib that we load from, but in Windows where there is a
separate python3.dll this would not work as the symbol would not have
been exposed in this more limited DLL file. This makes it much clearer
under what condition is this function needed.
closes: #12032
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
2023-08-20 21:18:38 +02:00
|
|
|
# undef PyUnicode_CompareWithASCIIString
|
|
|
|
# define PyUnicode_CompareWithASCIIString py3_PyUnicode_CompareWithASCIIString
|
2011-06-19 00:27:51 +02:00
|
|
|
# undef PyUnicode_AsEncodedString
|
|
|
|
# define PyUnicode_AsEncodedString py3_PyUnicode_AsEncodedString
|
patch 9.0.1776: No support for stable Python 3 ABI
Problem: No support for stable Python 3 ABI
Solution: Support Python 3 stable ABI
Commits:
1) Support Python 3 stable ABI to allow mixed version interoperatbility
Vim currently supports embedding Python for use with plugins, and the
"dynamic" linking option allows the user to specify a locally installed
version of Python by setting `pythonthreedll`. However, one caveat is
that the Python 3 libs are not binary compatible across minor versions,
and mixing versions can potentially be dangerous (e.g. let's say Vim was
linked against the Python 3.10 SDK, but the user sets `pythonthreedll`
to a 3.11 lib). Usually, nothing bad happens, but in theory this could
lead to crashes, memory corruption, and other unpredictable behaviors.
It's also difficult for the user to tell something is wrong because Vim
has no way of reporting what Python 3 version Vim was linked with.
For Vim installed via a package manager, this usually isn't an issue
because all the dependencies would already be figured out. For prebuilt
Vim binaries like MacVim (my motivation for working on this), AppImage,
and Win32 installer this could potentially be an issue as usually a
single binary is distributed. This is more tricky when a new Python
version is released, as there's a chicken-and-egg issue with deciding
what Python version to build against and hard to keep in sync when a new
Python version just drops and we have a mix of users of different Python
versions, and a user just blindly upgrading to a new Python could lead to
bad interactions with Vim.
Python 3 does have a solution for this problem: stable ABI / limited API
(see https://docs.python.org/3/c-api/stable.html). The C SDK limits the
API to a set of functions that are promised to be stable across
versions. This pull request adds an ifdef config that allows us to turn
it on when building Vim. Vim binaries built with this option should be
safe to freely link with any Python 3 libraies without having the
constraint of having to use the same minor version.
Note: Python 2 has no such concept and this doesn't change how Python 2
integration works (not that there is going to be a new version of Python
2 that would cause compatibility issues in the future anyway).
---
Technical details:
======
The stable ABI can be accessed when we compile with the Python 3 limited
API (by defining `Py_LIMITED_API`). The Python 3 code (in `if_python3.c`
and `if_py_both.h`) would now handle this and switch to limited API
mode. Without it set, Vim will still use the full API as before so this
is an opt-in change.
The main difference is that `PyType_Object` is now an opaque struct that
we can't directly create "static types" out of, and we have to create
type objects as "heap types" instead. This is because the struct is not
stable and changes from version to version (e.g. 3.8 added a
`tp_vectorcall` field to it). I had to change all the types to be
allocated on the heap instead with just a pointer to them.
Other functions are also simply missing in limited API, or they are
introduced too late (e.g. `PyUnicode_AsUTF8AndSize` in 3.10) to it that
we need some other ways to do the same thing, so I had to abstract a few
things into macros, and sometimes re-implement functions like
`PyObject_NEW`.
One caveat is that in limited API, `OutputType` (used for replacing
`sys.stdout`) no longer inherits from `PyStdPrinter_Type` which I don't
think has any real issue other than minor differences in how they
convert to a string and missing a couple functions like `mode()` and
`fileno()`.
Also fixed an existing bug where `tp_basicsize` was set incorrectly for
`BufferObject`, `TabListObject, `WinListObject`.
Technically, there could be a small performance drop, there is a little
more indirection with accessing type objects, and some APIs like
`PyUnicode_AsUTF8AndSize` are missing, but in practice I didn't see any
difference, and any well-written Python plugin should try to avoid
excessing callbacks to the `vim` module in Python anyway.
I only tested limited API mode down to Python 3.7, which seemes to
compile and work fine. I haven't tried earlier Python versions.
2) Fix PyIter_Check on older Python vers / type##Ptr unused warning
For PyIter_Check, older versions exposed them as either macros (used in
full API), or a function (for use in limited API). A previous change
exposed PyIter_Check to the dynamic build because Python just moved it
to function-only in 3.10 anyway. Because of that, just make sure we
always grab the function in dynamic builds in earlier versions since
that's what Python eventually did anyway.
3) Move Py_LIMITED_API define to configure script
Can now use --with-python-stable-abi flag to customize what stable ABI
version to target. Can also use an env var to do so as well.
4) Show +python/dyn-stable in :version, and allow has() feature query
Not sure if the "/dyn-stable" suffix would break things, or whether we
should do it another way. Or just don't show it in version and rely on
has() feature checking.
5) Documentation first draft. Still need to implement v:python3_version
6) Fix PyIter_Check build breaks when compiling against Python 3.8
7) Add CI coverage stable ABI on Linux/Windows / make configurable on Windows
This adds configurable options for Windows make files (both MinGW and
MSVC). CI will also now exercise both traditional full API and stable
ABI for Linux and Windows in the matrix for coverage.
Also added a "dynamic" option to Linux matrix as a drive-by change to
make other scripting languages like Ruby / Perl testable under both
static and dynamic builds.
8) Fix inaccuracy in Windows docs
Python's own docs are confusing but you don't actually want to use
`python3.dll` for the dynamic linkage.
9) Add generated autoconf file
10) Add v:python3_version support
This variable indicates the version of Python3 that Vim was built
against (PY_VERSION_HEX), and will be useful to check whether the Python
library you are loading in dynamically actually fits it. When built with
stable ABI, it will be the limited ABI version instead
(`Py_LIMITED_API`), which indicates the minimum version of Python 3 the
user should have, rather than the exact match. When stable ABI is used,
we won't be exposing PY_VERSION_HEX in this var because it just doesn't
seem necessary to do so (the whole point of stable ABI is the promise
that it will work across versions), and I don't want to confuse the user
with too many variables.
Also, cleaned up some documentation, and added help tags.
11) Fix Python 3.7 compat issues
Fix a couple issues when using limited API < 3.8
- Crash on exit: In Python 3.7, if a heap-allocated type is destroyed
before all instances are, it would cause a crash later. This happens
when we destroyed `OptionsType` before calling `Py_Finalize` when
using the limited API. To make it worse, later versions changed the
semantics and now each instance has a strong reference to its own type
and the recommendation has changed to have each instance de-ref its
own type and have its type in GC traversal. To avoid dealing with
these cross-version variations, we just don't free the heap type. They
are static types in non-limited-API anyway and are designed to last
through the entirety of the app, and we also don't restart the Python
runtime and therefore do not need it to have absolutely 0 leaks.
See:
- https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-c-api
- https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api
- PyIter_Check: This function is not provided in limited APIs older than
3.8. Previously I was trying to mock it out using manual
PyType_GetSlot() but it was brittle and also does not actually work
properly for static types (it will generate a Python error). Just
return false. It does mean using limited API < 3.8 is not recommended
as you lose the functionality to handle iterators, but from playing
with plugins I couldn't find it to be an issue.
- Fix loading of PyIter_Check so it will be done when limited API < 3.8.
Otherwise loading a 3.7 Python lib will fail even if limited API was
specified to use it.
12) Make sure to only load `PyUnicode_AsUTF8AndSize` in needed in limited API
We don't use this function unless limited API >= 3.10, but we were
loading it regardless. Usually it's ok in Unix-like systems where Python
just has a single lib that we load from, but in Windows where there is a
separate python3.dll this would not work as the symbol would not have
been exposed in this more limited DLL file. This makes it much clearer
under what condition is this function needed.
closes: #12032
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
2023-08-20 21:18:38 +02:00
|
|
|
# undef PyUnicode_AsUTF8String
|
|
|
|
# define PyUnicode_AsUTF8String py3_PyUnicode_AsUTF8String
|
2011-06-19 00:27:51 +02:00
|
|
|
# undef PyBytes_AsString
|
|
|
|
# define PyBytes_AsString py3_PyBytes_AsString
|
2013-07-03 18:49:17 +02:00
|
|
|
# ifndef PyBytes_AsStringAndSize
|
|
|
|
# define PyBytes_AsStringAndSize py3_PyBytes_AsStringAndSize
|
|
|
|
# endif
|
2012-06-29 12:54:53 +02:00
|
|
|
# undef PyBytes_FromString
|
|
|
|
# define PyBytes_FromString py3_PyBytes_FromString
|
2019-01-12 22:47:31 +01:00
|
|
|
# undef PyBytes_FromStringAndSize
|
|
|
|
# define PyBytes_FromStringAndSize py3_PyBytes_FromStringAndSize
|
2012-06-29 12:54:53 +02:00
|
|
|
# define PyFloat_FromDouble py3_PyFloat_FromDouble
|
|
|
|
# define PyFloat_AsDouble py3_PyFloat_AsDouble
|
2010-07-17 21:19:38 +02:00
|
|
|
# define PyObject_GenericGetAttr py3_PyObject_GenericGetAttr
|
2012-09-21 14:00:35 +02:00
|
|
|
# define PyType_Type (*py3_PyType_Type)
|
2023-10-04 20:05:05 +02:00
|
|
|
# ifndef USE_LIMITED_API
|
|
|
|
# define PyStdPrinter_Type (*py3_PyStdPrinter_Type)
|
|
|
|
# endif
|
2010-07-17 21:19:38 +02:00
|
|
|
# define PySlice_Type (*py3_PySlice_Type)
|
2012-06-29 12:54:53 +02:00
|
|
|
# define PyFloat_Type (*py3_PyFloat_Type)
|
2013-06-23 14:16:57 +02:00
|
|
|
# define PyNumber_Check (*py3_PyNumber_Check)
|
|
|
|
# define PyNumber_Long (*py3_PyNumber_Long)
|
2023-10-06 19:27:13 +02:00
|
|
|
# define PyBool_Type (*py3_PyBool_Type)
|
2011-06-19 00:27:51 +02:00
|
|
|
# define PyErr_NewException py3_PyErr_NewException
|
2010-08-09 22:06:13 +02:00
|
|
|
# ifdef Py_DEBUG
|
|
|
|
# define _Py_NegativeRefcount py3__Py_NegativeRefcount
|
|
|
|
# define _Py_RefTotal (*py3__Py_RefTotal)
|
2013-05-29 21:33:39 +02:00
|
|
|
# define PyModule_Create2TraceRefs py3_PyModule_Create2TraceRefs
|
|
|
|
# else
|
|
|
|
# define PyModule_Create2 py3_PyModule_Create2
|
|
|
|
# endif
|
|
|
|
# if defined(Py_DEBUG) && !defined(Py_DEBUG_NO_PYMALLOC)
|
2010-08-09 22:06:13 +02:00
|
|
|
# define _PyObject_DebugMalloc py3__PyObject_DebugMalloc
|
|
|
|
# define _PyObject_DebugFree py3__PyObject_DebugFree
|
|
|
|
# else
|
|
|
|
# define PyObject_Malloc py3_PyObject_Malloc
|
|
|
|
# define PyObject_Free py3_PyObject_Free
|
|
|
|
# endif
|
2013-05-21 20:51:59 +02:00
|
|
|
# define _PyObject_GC_New py3__PyObject_GC_New
|
|
|
|
# define PyObject_GC_Del py3_PyObject_GC_Del
|
|
|
|
# define PyObject_GC_UnTrack py3_PyObject_GC_UnTrack
|
2010-07-17 21:19:38 +02:00
|
|
|
# define PyType_GenericAlloc py3_PyType_GenericAlloc
|
|
|
|
# define PyType_GenericNew py3_PyType_GenericNew
|
2010-08-09 22:06:13 +02:00
|
|
|
# undef PyUnicode_FromString
|
2010-07-17 21:19:38 +02:00
|
|
|
# define PyUnicode_FromString py3_PyUnicode_FromString
|
2023-10-11 21:27:06 +02:00
|
|
|
# ifdef Py_UNICODE_USE_UCS_FUNCTIONS
|
2013-05-30 12:40:39 +02:00
|
|
|
# ifdef Py_UNICODE_WIDE
|
|
|
|
# define PyUnicodeUCS4_FromFormat py3_PyUnicodeUCS4_FromFormat
|
|
|
|
# else
|
|
|
|
# define PyUnicodeUCS2_FromFormat py3_PyUnicodeUCS2_FromFormat
|
|
|
|
# endif
|
2023-10-11 21:27:06 +02:00
|
|
|
# else
|
|
|
|
# define PyUnicode_FromFormat py3_PyUnicode_FromFormat
|
2013-05-30 12:40:39 +02:00
|
|
|
# endif
|
2011-06-19 00:27:51 +02:00
|
|
|
# undef PyUnicode_Decode
|
|
|
|
# define PyUnicode_Decode py3_PyUnicode_Decode
|
2012-06-29 12:54:53 +02:00
|
|
|
# define PyType_IsSubtype py3_PyType_IsSubtype
|
|
|
|
# define PyCapsule_New py3_PyCapsule_New
|
|
|
|
# define PyCapsule_GetPointer py3_PyCapsule_GetPointer
|
patch 9.0.1776: No support for stable Python 3 ABI
Problem: No support for stable Python 3 ABI
Solution: Support Python 3 stable ABI
Commits:
1) Support Python 3 stable ABI to allow mixed version interoperatbility
Vim currently supports embedding Python for use with plugins, and the
"dynamic" linking option allows the user to specify a locally installed
version of Python by setting `pythonthreedll`. However, one caveat is
that the Python 3 libs are not binary compatible across minor versions,
and mixing versions can potentially be dangerous (e.g. let's say Vim was
linked against the Python 3.10 SDK, but the user sets `pythonthreedll`
to a 3.11 lib). Usually, nothing bad happens, but in theory this could
lead to crashes, memory corruption, and other unpredictable behaviors.
It's also difficult for the user to tell something is wrong because Vim
has no way of reporting what Python 3 version Vim was linked with.
For Vim installed via a package manager, this usually isn't an issue
because all the dependencies would already be figured out. For prebuilt
Vim binaries like MacVim (my motivation for working on this), AppImage,
and Win32 installer this could potentially be an issue as usually a
single binary is distributed. This is more tricky when a new Python
version is released, as there's a chicken-and-egg issue with deciding
what Python version to build against and hard to keep in sync when a new
Python version just drops and we have a mix of users of different Python
versions, and a user just blindly upgrading to a new Python could lead to
bad interactions with Vim.
Python 3 does have a solution for this problem: stable ABI / limited API
(see https://docs.python.org/3/c-api/stable.html). The C SDK limits the
API to a set of functions that are promised to be stable across
versions. This pull request adds an ifdef config that allows us to turn
it on when building Vim. Vim binaries built with this option should be
safe to freely link with any Python 3 libraies without having the
constraint of having to use the same minor version.
Note: Python 2 has no such concept and this doesn't change how Python 2
integration works (not that there is going to be a new version of Python
2 that would cause compatibility issues in the future anyway).
---
Technical details:
======
The stable ABI can be accessed when we compile with the Python 3 limited
API (by defining `Py_LIMITED_API`). The Python 3 code (in `if_python3.c`
and `if_py_both.h`) would now handle this and switch to limited API
mode. Without it set, Vim will still use the full API as before so this
is an opt-in change.
The main difference is that `PyType_Object` is now an opaque struct that
we can't directly create "static types" out of, and we have to create
type objects as "heap types" instead. This is because the struct is not
stable and changes from version to version (e.g. 3.8 added a
`tp_vectorcall` field to it). I had to change all the types to be
allocated on the heap instead with just a pointer to them.
Other functions are also simply missing in limited API, or they are
introduced too late (e.g. `PyUnicode_AsUTF8AndSize` in 3.10) to it that
we need some other ways to do the same thing, so I had to abstract a few
things into macros, and sometimes re-implement functions like
`PyObject_NEW`.
One caveat is that in limited API, `OutputType` (used for replacing
`sys.stdout`) no longer inherits from `PyStdPrinter_Type` which I don't
think has any real issue other than minor differences in how they
convert to a string and missing a couple functions like `mode()` and
`fileno()`.
Also fixed an existing bug where `tp_basicsize` was set incorrectly for
`BufferObject`, `TabListObject, `WinListObject`.
Technically, there could be a small performance drop, there is a little
more indirection with accessing type objects, and some APIs like
`PyUnicode_AsUTF8AndSize` are missing, but in practice I didn't see any
difference, and any well-written Python plugin should try to avoid
excessing callbacks to the `vim` module in Python anyway.
I only tested limited API mode down to Python 3.7, which seemes to
compile and work fine. I haven't tried earlier Python versions.
2) Fix PyIter_Check on older Python vers / type##Ptr unused warning
For PyIter_Check, older versions exposed them as either macros (used in
full API), or a function (for use in limited API). A previous change
exposed PyIter_Check to the dynamic build because Python just moved it
to function-only in 3.10 anyway. Because of that, just make sure we
always grab the function in dynamic builds in earlier versions since
that's what Python eventually did anyway.
3) Move Py_LIMITED_API define to configure script
Can now use --with-python-stable-abi flag to customize what stable ABI
version to target. Can also use an env var to do so as well.
4) Show +python/dyn-stable in :version, and allow has() feature query
Not sure if the "/dyn-stable" suffix would break things, or whether we
should do it another way. Or just don't show it in version and rely on
has() feature checking.
5) Documentation first draft. Still need to implement v:python3_version
6) Fix PyIter_Check build breaks when compiling against Python 3.8
7) Add CI coverage stable ABI on Linux/Windows / make configurable on Windows
This adds configurable options for Windows make files (both MinGW and
MSVC). CI will also now exercise both traditional full API and stable
ABI for Linux and Windows in the matrix for coverage.
Also added a "dynamic" option to Linux matrix as a drive-by change to
make other scripting languages like Ruby / Perl testable under both
static and dynamic builds.
8) Fix inaccuracy in Windows docs
Python's own docs are confusing but you don't actually want to use
`python3.dll` for the dynamic linkage.
9) Add generated autoconf file
10) Add v:python3_version support
This variable indicates the version of Python3 that Vim was built
against (PY_VERSION_HEX), and will be useful to check whether the Python
library you are loading in dynamically actually fits it. When built with
stable ABI, it will be the limited ABI version instead
(`Py_LIMITED_API`), which indicates the minimum version of Python 3 the
user should have, rather than the exact match. When stable ABI is used,
we won't be exposing PY_VERSION_HEX in this var because it just doesn't
seem necessary to do so (the whole point of stable ABI is the promise
that it will work across versions), and I don't want to confuse the user
with too many variables.
Also, cleaned up some documentation, and added help tags.
11) Fix Python 3.7 compat issues
Fix a couple issues when using limited API < 3.8
- Crash on exit: In Python 3.7, if a heap-allocated type is destroyed
before all instances are, it would cause a crash later. This happens
when we destroyed `OptionsType` before calling `Py_Finalize` when
using the limited API. To make it worse, later versions changed the
semantics and now each instance has a strong reference to its own type
and the recommendation has changed to have each instance de-ref its
own type and have its type in GC traversal. To avoid dealing with
these cross-version variations, we just don't free the heap type. They
are static types in non-limited-API anyway and are designed to last
through the entirety of the app, and we also don't restart the Python
runtime and therefore do not need it to have absolutely 0 leaks.
See:
- https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-c-api
- https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api
- PyIter_Check: This function is not provided in limited APIs older than
3.8. Previously I was trying to mock it out using manual
PyType_GetSlot() but it was brittle and also does not actually work
properly for static types (it will generate a Python error). Just
return false. It does mean using limited API < 3.8 is not recommended
as you lose the functionality to handle iterators, but from playing
with plugins I couldn't find it to be an issue.
- Fix loading of PyIter_Check so it will be done when limited API < 3.8.
Otherwise loading a 3.7 Python lib will fail even if limited API was
specified to use it.
12) Make sure to only load `PyUnicode_AsUTF8AndSize` in needed in limited API
We don't use this function unless limited API >= 3.10, but we were
loading it regardless. Usually it's ok in Unix-like systems where Python
just has a single lib that we load from, but in Windows where there is a
separate python3.dll this would not work as the symbol would not have
been exposed in this more limited DLL file. This makes it much clearer
under what condition is this function needed.
closes: #12032
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
2023-08-20 21:18:38 +02:00
|
|
|
# ifdef USE_LIMITED_API
|
|
|
|
# define PyType_GetSlot py3_PyType_GetSlot
|
|
|
|
# define PyType_FromSpec py3_PyType_FromSpec
|
|
|
|
# endif
|
2010-07-17 21:19:38 +02:00
|
|
|
|
2013-05-29 21:33:39 +02:00
|
|
|
# if defined(Py_DEBUG) && !defined(Py_DEBUG_NO_PYMALLOC)
|
2010-08-09 22:06:13 +02:00
|
|
|
# undef PyObject_NEW
|
|
|
|
# define PyObject_NEW(type, typeobj) \
|
2010-07-17 21:19:38 +02:00
|
|
|
( (type *) PyObject_Init( \
|
2010-07-17 23:52:29 +02:00
|
|
|
(PyObject *) _PyObject_DebugMalloc( _PyObject_SIZE(typeobj) ), (typeobj)) )
|
2020-07-16 22:15:53 +02:00
|
|
|
# elif PY_VERSION_HEX >= 0x030900b0
|
|
|
|
# undef PyObject_NEW
|
|
|
|
# define PyObject_NEW(type, typeobj) \
|
|
|
|
((type *)py3__PyObject_New(typeobj))
|
2010-08-09 22:06:13 +02:00
|
|
|
# endif
|
|
|
|
|
2010-07-17 21:19:38 +02:00
|
|
|
/*
|
|
|
|
* Pointers for dynamic link
|
|
|
|
*/
|
|
|
|
static int (*py3_PySys_SetArgv)(int, wchar_t **);
|
2010-11-16 19:26:02 +01:00
|
|
|
static void (*py3_Py_SetPythonHome)(wchar_t *home);
|
2010-07-17 21:19:38 +02:00
|
|
|
static void (*py3_Py_Initialize)(void);
|
|
|
|
static PyObject* (*py3_PyList_New)(Py_ssize_t size);
|
|
|
|
static PyGILState_STATE (*py3_PyGILState_Ensure)(void);
|
|
|
|
static void (*py3_PyGILState_Release)(PyGILState_STATE);
|
|
|
|
static int (*py3_PySys_SetObject)(char *, PyObject *);
|
2013-06-10 21:27:29 +02:00
|
|
|
static PyObject* (*py3_PySys_GetObject)(char *);
|
|
|
|
static int (*py3_PyList_Append)(PyObject *, PyObject *);
|
|
|
|
static int (*py3_PyList_Insert)(PyObject *, int, PyObject *);
|
2010-07-17 21:19:38 +02:00
|
|
|
static Py_ssize_t (*py3_PyList_Size)(PyObject *);
|
2012-06-29 12:54:53 +02:00
|
|
|
static int (*py3_PySequence_Check)(PyObject *);
|
|
|
|
static Py_ssize_t (*py3_PySequence_Size)(PyObject *);
|
|
|
|
static PyObject* (*py3_PySequence_GetItem)(PyObject *, Py_ssize_t);
|
2013-05-30 13:01:18 +02:00
|
|
|
static PyObject* (*py3_PySequence_Fast)(PyObject *, const char *);
|
2012-06-29 12:54:53 +02:00
|
|
|
static Py_ssize_t (*py3_PyTuple_Size)(PyObject *);
|
|
|
|
static PyObject* (*py3_PyTuple_GetItem)(PyObject *, Py_ssize_t);
|
|
|
|
static int (*py3_PyMapping_Check)(PyObject *);
|
2013-05-30 13:22:13 +02:00
|
|
|
static PyObject* (*py3_PyMapping_Keys)(PyObject *);
|
2018-07-04 22:03:25 +02:00
|
|
|
# if PY_VERSION_HEX >= 0x030601f0
|
|
|
|
static int (*py3_PySlice_AdjustIndices)(Py_ssize_t length,
|
|
|
|
Py_ssize_t *start, Py_ssize_t *stop, Py_ssize_t step);
|
|
|
|
static int (*py3_PySlice_Unpack)(PyObject *slice,
|
|
|
|
Py_ssize_t *start, Py_ssize_t *stop, Py_ssize_t *step);
|
|
|
|
# endif
|
2014-03-30 16:11:43 +02:00
|
|
|
static int (*py3_PySlice_GetIndicesEx)(PySliceObject_T *r, Py_ssize_t length,
|
2014-01-14 16:36:51 +01:00
|
|
|
Py_ssize_t *start, Py_ssize_t *stop, Py_ssize_t *step,
|
|
|
|
Py_ssize_t *slicelen);
|
2010-07-17 21:19:38 +02:00
|
|
|
static PyObject* (*py3_PyErr_NoMemory)(void);
|
|
|
|
static void (*py3_Py_Finalize)(void);
|
|
|
|
static void (*py3_PyErr_SetString)(PyObject *, const char *);
|
2013-05-15 15:35:09 +02:00
|
|
|
static void (*py3_PyErr_SetObject)(PyObject *, PyObject *);
|
2013-06-10 21:27:29 +02:00
|
|
|
static int (*py3_PyErr_ExceptionMatches)(PyObject *);
|
2024-09-10 20:56:13 +02:00
|
|
|
# if defined(USE_LIMITED_API) || PY_VERSION_HEX >= 0x03080000
|
2024-08-10 09:44:20 +02:00
|
|
|
static void (*py3_Py_IncRef)(PyObject *);
|
2024-09-09 19:55:24 +02:00
|
|
|
static void (*py3_Py_DecRef)(PyObject *);
|
2024-08-10 09:44:20 +02:00
|
|
|
# endif
|
2023-10-11 21:27:06 +02:00
|
|
|
# ifdef USE_LIMITED_API
|
patch 9.0.1776: No support for stable Python 3 ABI
Problem: No support for stable Python 3 ABI
Solution: Support Python 3 stable ABI
Commits:
1) Support Python 3 stable ABI to allow mixed version interoperatbility
Vim currently supports embedding Python for use with plugins, and the
"dynamic" linking option allows the user to specify a locally installed
version of Python by setting `pythonthreedll`. However, one caveat is
that the Python 3 libs are not binary compatible across minor versions,
and mixing versions can potentially be dangerous (e.g. let's say Vim was
linked against the Python 3.10 SDK, but the user sets `pythonthreedll`
to a 3.11 lib). Usually, nothing bad happens, but in theory this could
lead to crashes, memory corruption, and other unpredictable behaviors.
It's also difficult for the user to tell something is wrong because Vim
has no way of reporting what Python 3 version Vim was linked with.
For Vim installed via a package manager, this usually isn't an issue
because all the dependencies would already be figured out. For prebuilt
Vim binaries like MacVim (my motivation for working on this), AppImage,
and Win32 installer this could potentially be an issue as usually a
single binary is distributed. This is more tricky when a new Python
version is released, as there's a chicken-and-egg issue with deciding
what Python version to build against and hard to keep in sync when a new
Python version just drops and we have a mix of users of different Python
versions, and a user just blindly upgrading to a new Python could lead to
bad interactions with Vim.
Python 3 does have a solution for this problem: stable ABI / limited API
(see https://docs.python.org/3/c-api/stable.html). The C SDK limits the
API to a set of functions that are promised to be stable across
versions. This pull request adds an ifdef config that allows us to turn
it on when building Vim. Vim binaries built with this option should be
safe to freely link with any Python 3 libraies without having the
constraint of having to use the same minor version.
Note: Python 2 has no such concept and this doesn't change how Python 2
integration works (not that there is going to be a new version of Python
2 that would cause compatibility issues in the future anyway).
---
Technical details:
======
The stable ABI can be accessed when we compile with the Python 3 limited
API (by defining `Py_LIMITED_API`). The Python 3 code (in `if_python3.c`
and `if_py_both.h`) would now handle this and switch to limited API
mode. Without it set, Vim will still use the full API as before so this
is an opt-in change.
The main difference is that `PyType_Object` is now an opaque struct that
we can't directly create "static types" out of, and we have to create
type objects as "heap types" instead. This is because the struct is not
stable and changes from version to version (e.g. 3.8 added a
`tp_vectorcall` field to it). I had to change all the types to be
allocated on the heap instead with just a pointer to them.
Other functions are also simply missing in limited API, or they are
introduced too late (e.g. `PyUnicode_AsUTF8AndSize` in 3.10) to it that
we need some other ways to do the same thing, so I had to abstract a few
things into macros, and sometimes re-implement functions like
`PyObject_NEW`.
One caveat is that in limited API, `OutputType` (used for replacing
`sys.stdout`) no longer inherits from `PyStdPrinter_Type` which I don't
think has any real issue other than minor differences in how they
convert to a string and missing a couple functions like `mode()` and
`fileno()`.
Also fixed an existing bug where `tp_basicsize` was set incorrectly for
`BufferObject`, `TabListObject, `WinListObject`.
Technically, there could be a small performance drop, there is a little
more indirection with accessing type objects, and some APIs like
`PyUnicode_AsUTF8AndSize` are missing, but in practice I didn't see any
difference, and any well-written Python plugin should try to avoid
excessing callbacks to the `vim` module in Python anyway.
I only tested limited API mode down to Python 3.7, which seemes to
compile and work fine. I haven't tried earlier Python versions.
2) Fix PyIter_Check on older Python vers / type##Ptr unused warning
For PyIter_Check, older versions exposed them as either macros (used in
full API), or a function (for use in limited API). A previous change
exposed PyIter_Check to the dynamic build because Python just moved it
to function-only in 3.10 anyway. Because of that, just make sure we
always grab the function in dynamic builds in earlier versions since
that's what Python eventually did anyway.
3) Move Py_LIMITED_API define to configure script
Can now use --with-python-stable-abi flag to customize what stable ABI
version to target. Can also use an env var to do so as well.
4) Show +python/dyn-stable in :version, and allow has() feature query
Not sure if the "/dyn-stable" suffix would break things, or whether we
should do it another way. Or just don't show it in version and rely on
has() feature checking.
5) Documentation first draft. Still need to implement v:python3_version
6) Fix PyIter_Check build breaks when compiling against Python 3.8
7) Add CI coverage stable ABI on Linux/Windows / make configurable on Windows
This adds configurable options for Windows make files (both MinGW and
MSVC). CI will also now exercise both traditional full API and stable
ABI for Linux and Windows in the matrix for coverage.
Also added a "dynamic" option to Linux matrix as a drive-by change to
make other scripting languages like Ruby / Perl testable under both
static and dynamic builds.
8) Fix inaccuracy in Windows docs
Python's own docs are confusing but you don't actually want to use
`python3.dll` for the dynamic linkage.
9) Add generated autoconf file
10) Add v:python3_version support
This variable indicates the version of Python3 that Vim was built
against (PY_VERSION_HEX), and will be useful to check whether the Python
library you are loading in dynamically actually fits it. When built with
stable ABI, it will be the limited ABI version instead
(`Py_LIMITED_API`), which indicates the minimum version of Python 3 the
user should have, rather than the exact match. When stable ABI is used,
we won't be exposing PY_VERSION_HEX in this var because it just doesn't
seem necessary to do so (the whole point of stable ABI is the promise
that it will work across versions), and I don't want to confuse the user
with too many variables.
Also, cleaned up some documentation, and added help tags.
11) Fix Python 3.7 compat issues
Fix a couple issues when using limited API < 3.8
- Crash on exit: In Python 3.7, if a heap-allocated type is destroyed
before all instances are, it would cause a crash later. This happens
when we destroyed `OptionsType` before calling `Py_Finalize` when
using the limited API. To make it worse, later versions changed the
semantics and now each instance has a strong reference to its own type
and the recommendation has changed to have each instance de-ref its
own type and have its type in GC traversal. To avoid dealing with
these cross-version variations, we just don't free the heap type. They
are static types in non-limited-API anyway and are designed to last
through the entirety of the app, and we also don't restart the Python
runtime and therefore do not need it to have absolutely 0 leaks.
See:
- https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-c-api
- https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api
- PyIter_Check: This function is not provided in limited APIs older than
3.8. Previously I was trying to mock it out using manual
PyType_GetSlot() but it was brittle and also does not actually work
properly for static types (it will generate a Python error). Just
return false. It does mean using limited API < 3.8 is not recommended
as you lose the functionality to handle iterators, but from playing
with plugins I couldn't find it to be an issue.
- Fix loading of PyIter_Check so it will be done when limited API < 3.8.
Otherwise loading a 3.7 Python lib will fail even if limited API was
specified to use it.
12) Make sure to only load `PyUnicode_AsUTF8AndSize` in needed in limited API
We don't use this function unless limited API >= 3.10, but we were
loading it regardless. Usually it's ok in Unix-like systems where Python
just has a single lib that we load from, but in Windows where there is a
separate python3.dll this would not work as the symbol would not have
been exposed in this more limited DLL file. This makes it much clearer
under what condition is this function needed.
closes: #12032
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
2023-08-20 21:18:38 +02:00
|
|
|
static PyObject* (*py3_Py_CompileString)(const char *, const char *, int);
|
|
|
|
static PyObject* (*py3_PyEval_EvalCode)(PyObject *co, PyObject *globals, PyObject *locals);
|
2023-10-11 21:27:06 +02:00
|
|
|
# else
|
|
|
|
static int (*py3_PyRun_SimpleString)(char *);
|
|
|
|
static PyObject* (*py3_PyRun_String)(char *, int, PyObject *, PyObject *);
|
patch 9.0.1776: No support for stable Python 3 ABI
Problem: No support for stable Python 3 ABI
Solution: Support Python 3 stable ABI
Commits:
1) Support Python 3 stable ABI to allow mixed version interoperatbility
Vim currently supports embedding Python for use with plugins, and the
"dynamic" linking option allows the user to specify a locally installed
version of Python by setting `pythonthreedll`. However, one caveat is
that the Python 3 libs are not binary compatible across minor versions,
and mixing versions can potentially be dangerous (e.g. let's say Vim was
linked against the Python 3.10 SDK, but the user sets `pythonthreedll`
to a 3.11 lib). Usually, nothing bad happens, but in theory this could
lead to crashes, memory corruption, and other unpredictable behaviors.
It's also difficult for the user to tell something is wrong because Vim
has no way of reporting what Python 3 version Vim was linked with.
For Vim installed via a package manager, this usually isn't an issue
because all the dependencies would already be figured out. For prebuilt
Vim binaries like MacVim (my motivation for working on this), AppImage,
and Win32 installer this could potentially be an issue as usually a
single binary is distributed. This is more tricky when a new Python
version is released, as there's a chicken-and-egg issue with deciding
what Python version to build against and hard to keep in sync when a new
Python version just drops and we have a mix of users of different Python
versions, and a user just blindly upgrading to a new Python could lead to
bad interactions with Vim.
Python 3 does have a solution for this problem: stable ABI / limited API
(see https://docs.python.org/3/c-api/stable.html). The C SDK limits the
API to a set of functions that are promised to be stable across
versions. This pull request adds an ifdef config that allows us to turn
it on when building Vim. Vim binaries built with this option should be
safe to freely link with any Python 3 libraies without having the
constraint of having to use the same minor version.
Note: Python 2 has no such concept and this doesn't change how Python 2
integration works (not that there is going to be a new version of Python
2 that would cause compatibility issues in the future anyway).
---
Technical details:
======
The stable ABI can be accessed when we compile with the Python 3 limited
API (by defining `Py_LIMITED_API`). The Python 3 code (in `if_python3.c`
and `if_py_both.h`) would now handle this and switch to limited API
mode. Without it set, Vim will still use the full API as before so this
is an opt-in change.
The main difference is that `PyType_Object` is now an opaque struct that
we can't directly create "static types" out of, and we have to create
type objects as "heap types" instead. This is because the struct is not
stable and changes from version to version (e.g. 3.8 added a
`tp_vectorcall` field to it). I had to change all the types to be
allocated on the heap instead with just a pointer to them.
Other functions are also simply missing in limited API, or they are
introduced too late (e.g. `PyUnicode_AsUTF8AndSize` in 3.10) to it that
we need some other ways to do the same thing, so I had to abstract a few
things into macros, and sometimes re-implement functions like
`PyObject_NEW`.
One caveat is that in limited API, `OutputType` (used for replacing
`sys.stdout`) no longer inherits from `PyStdPrinter_Type` which I don't
think has any real issue other than minor differences in how they
convert to a string and missing a couple functions like `mode()` and
`fileno()`.
Also fixed an existing bug where `tp_basicsize` was set incorrectly for
`BufferObject`, `TabListObject, `WinListObject`.
Technically, there could be a small performance drop, there is a little
more indirection with accessing type objects, and some APIs like
`PyUnicode_AsUTF8AndSize` are missing, but in practice I didn't see any
difference, and any well-written Python plugin should try to avoid
excessing callbacks to the `vim` module in Python anyway.
I only tested limited API mode down to Python 3.7, which seemes to
compile and work fine. I haven't tried earlier Python versions.
2) Fix PyIter_Check on older Python vers / type##Ptr unused warning
For PyIter_Check, older versions exposed them as either macros (used in
full API), or a function (for use in limited API). A previous change
exposed PyIter_Check to the dynamic build because Python just moved it
to function-only in 3.10 anyway. Because of that, just make sure we
always grab the function in dynamic builds in earlier versions since
that's what Python eventually did anyway.
3) Move Py_LIMITED_API define to configure script
Can now use --with-python-stable-abi flag to customize what stable ABI
version to target. Can also use an env var to do so as well.
4) Show +python/dyn-stable in :version, and allow has() feature query
Not sure if the "/dyn-stable" suffix would break things, or whether we
should do it another way. Or just don't show it in version and rely on
has() feature checking.
5) Documentation first draft. Still need to implement v:python3_version
6) Fix PyIter_Check build breaks when compiling against Python 3.8
7) Add CI coverage stable ABI on Linux/Windows / make configurable on Windows
This adds configurable options for Windows make files (both MinGW and
MSVC). CI will also now exercise both traditional full API and stable
ABI for Linux and Windows in the matrix for coverage.
Also added a "dynamic" option to Linux matrix as a drive-by change to
make other scripting languages like Ruby / Perl testable under both
static and dynamic builds.
8) Fix inaccuracy in Windows docs
Python's own docs are confusing but you don't actually want to use
`python3.dll` for the dynamic linkage.
9) Add generated autoconf file
10) Add v:python3_version support
This variable indicates the version of Python3 that Vim was built
against (PY_VERSION_HEX), and will be useful to check whether the Python
library you are loading in dynamically actually fits it. When built with
stable ABI, it will be the limited ABI version instead
(`Py_LIMITED_API`), which indicates the minimum version of Python 3 the
user should have, rather than the exact match. When stable ABI is used,
we won't be exposing PY_VERSION_HEX in this var because it just doesn't
seem necessary to do so (the whole point of stable ABI is the promise
that it will work across versions), and I don't want to confuse the user
with too many variables.
Also, cleaned up some documentation, and added help tags.
11) Fix Python 3.7 compat issues
Fix a couple issues when using limited API < 3.8
- Crash on exit: In Python 3.7, if a heap-allocated type is destroyed
before all instances are, it would cause a crash later. This happens
when we destroyed `OptionsType` before calling `Py_Finalize` when
using the limited API. To make it worse, later versions changed the
semantics and now each instance has a strong reference to its own type
and the recommendation has changed to have each instance de-ref its
own type and have its type in GC traversal. To avoid dealing with
these cross-version variations, we just don't free the heap type. They
are static types in non-limited-API anyway and are designed to last
through the entirety of the app, and we also don't restart the Python
runtime and therefore do not need it to have absolutely 0 leaks.
See:
- https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-c-api
- https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api
- PyIter_Check: This function is not provided in limited APIs older than
3.8. Previously I was trying to mock it out using manual
PyType_GetSlot() but it was brittle and also does not actually work
properly for static types (it will generate a Python error). Just
return false. It does mean using limited API < 3.8 is not recommended
as you lose the functionality to handle iterators, but from playing
with plugins I couldn't find it to be an issue.
- Fix loading of PyIter_Check so it will be done when limited API < 3.8.
Otherwise loading a 3.7 Python lib will fail even if limited API was
specified to use it.
12) Make sure to only load `PyUnicode_AsUTF8AndSize` in needed in limited API
We don't use this function unless limited API >= 3.10, but we were
loading it regardless. Usually it's ok in Unix-like systems where Python
just has a single lib that we load from, but in Windows where there is a
separate python3.dll this would not work as the symbol would not have
been exposed in this more limited DLL file. This makes it much clearer
under what condition is this function needed.
closes: #12032
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
2023-08-20 21:18:38 +02:00
|
|
|
# endif
|
2013-05-15 18:28:13 +02:00
|
|
|
static PyObject* (*py3_PyObject_GetAttrString)(PyObject *, const char *);
|
2013-05-30 13:01:18 +02:00
|
|
|
static int (*py3_PyObject_HasAttrString)(PyObject *, const char *);
|
2013-11-03 00:28:25 +01:00
|
|
|
static int (*py3_PyObject_SetAttrString)(PyObject *, const char *, PyObject *);
|
2013-05-15 18:28:13 +02:00
|
|
|
static PyObject* (*py3_PyObject_CallFunctionObjArgs)(PyObject *, ...);
|
2024-07-04 16:36:05 +02:00
|
|
|
# if PY_VERSION_HEX >= 0x030d0000
|
|
|
|
static PyObject* (*py3_PyObject_CallFunction)(PyObject *, char *, ...);
|
|
|
|
# else
|
2013-06-12 14:41:04 +02:00
|
|
|
static PyObject* (*py3__PyObject_CallFunction_SizeT)(PyObject *, char *, ...);
|
2024-07-04 16:36:05 +02:00
|
|
|
# endif
|
2013-06-02 18:20:17 +02:00
|
|
|
static PyObject* (*py3_PyObject_Call)(PyObject *, PyObject *, PyObject *);
|
patch 9.0.1960: Make CI checks more strict
Problem: Make CI checks more strict
Solution: Add -Wstrict-prototypes -Wmissing-prototypes to CI,
fix uncovered problems
Add -Wstrict-prototypes -Wmissing-prototypes warnings check to CI
Add two new warnings to CI, silence some Perl related build-warnings:
- `strict-prototypes` helps prevent declaring a function with an empty
argument list, e.g. `int func()`. In C++, that's equivalent to `int
func(void)`, but in C, that means a function that can take any number
of arguments which is rarely what we want.
- `missing-prototypes` makes sure we use `static` for file-only internal
functions. Non-static functions should have been declared on a
prototype file.
- Add `no-compound-token-split-by-macro` to the perl cflags, since it
throws out a bunch of perl-related warnings that make the CI log
unnecessary verbose and hard to read. This seems to happen only with
clang 12 and above.
When applying those changes, it already uncovered a few warnings, so fix
up the code as well (fix prototypes, make the code static, remove
shadowed var declaration)
GTK header needs to have #pragma warning suppressiong because GTK2
headers will warn on `-Wstrict-prototypes`, and it's included by gui.h
and so we can't just turn off the warning in a couple files.
closes: #13223
closes: #13226
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
2023-09-30 12:28:50 +02:00
|
|
|
static PyObject* (*py3_PyEval_GetGlobals)(void);
|
|
|
|
static PyObject* (*py3_PyEval_GetLocals)(void);
|
2010-07-17 21:19:38 +02:00
|
|
|
static PyObject* (*py3_PyList_GetItem)(PyObject *, Py_ssize_t);
|
|
|
|
static PyObject* (*py3_PyImport_ImportModule)(const char *);
|
2012-06-29 12:54:53 +02:00
|
|
|
static PyObject* (*py3_PyImport_AddModule)(const char *);
|
2010-07-17 21:19:38 +02:00
|
|
|
static int (*py3_PyErr_BadArgument)(void);
|
|
|
|
static PyObject* (*py3_PyErr_Occurred)(void);
|
|
|
|
static PyObject* (*py3_PyModule_GetDict)(PyObject *);
|
|
|
|
static int (*py3_PyList_SetItem)(PyObject *, Py_ssize_t, PyObject *);
|
|
|
|
static PyObject* (*py3_PyDict_GetItemString)(PyObject *, const char *);
|
2012-06-29 12:54:53 +02:00
|
|
|
static int (*py3_PyDict_Next)(PyObject *, Py_ssize_t *, PyObject **, PyObject **);
|
2010-07-17 21:19:38 +02:00
|
|
|
static PyObject* (*py3_PyLong_FromLong)(long);
|
|
|
|
static PyObject* (*py3_PyDict_New)(void);
|
patch 9.0.1776: No support for stable Python 3 ABI
Problem: No support for stable Python 3 ABI
Solution: Support Python 3 stable ABI
Commits:
1) Support Python 3 stable ABI to allow mixed version interoperatbility
Vim currently supports embedding Python for use with plugins, and the
"dynamic" linking option allows the user to specify a locally installed
version of Python by setting `pythonthreedll`. However, one caveat is
that the Python 3 libs are not binary compatible across minor versions,
and mixing versions can potentially be dangerous (e.g. let's say Vim was
linked against the Python 3.10 SDK, but the user sets `pythonthreedll`
to a 3.11 lib). Usually, nothing bad happens, but in theory this could
lead to crashes, memory corruption, and other unpredictable behaviors.
It's also difficult for the user to tell something is wrong because Vim
has no way of reporting what Python 3 version Vim was linked with.
For Vim installed via a package manager, this usually isn't an issue
because all the dependencies would already be figured out. For prebuilt
Vim binaries like MacVim (my motivation for working on this), AppImage,
and Win32 installer this could potentially be an issue as usually a
single binary is distributed. This is more tricky when a new Python
version is released, as there's a chicken-and-egg issue with deciding
what Python version to build against and hard to keep in sync when a new
Python version just drops and we have a mix of users of different Python
versions, and a user just blindly upgrading to a new Python could lead to
bad interactions with Vim.
Python 3 does have a solution for this problem: stable ABI / limited API
(see https://docs.python.org/3/c-api/stable.html). The C SDK limits the
API to a set of functions that are promised to be stable across
versions. This pull request adds an ifdef config that allows us to turn
it on when building Vim. Vim binaries built with this option should be
safe to freely link with any Python 3 libraies without having the
constraint of having to use the same minor version.
Note: Python 2 has no such concept and this doesn't change how Python 2
integration works (not that there is going to be a new version of Python
2 that would cause compatibility issues in the future anyway).
---
Technical details:
======
The stable ABI can be accessed when we compile with the Python 3 limited
API (by defining `Py_LIMITED_API`). The Python 3 code (in `if_python3.c`
and `if_py_both.h`) would now handle this and switch to limited API
mode. Without it set, Vim will still use the full API as before so this
is an opt-in change.
The main difference is that `PyType_Object` is now an opaque struct that
we can't directly create "static types" out of, and we have to create
type objects as "heap types" instead. This is because the struct is not
stable and changes from version to version (e.g. 3.8 added a
`tp_vectorcall` field to it). I had to change all the types to be
allocated on the heap instead with just a pointer to them.
Other functions are also simply missing in limited API, or they are
introduced too late (e.g. `PyUnicode_AsUTF8AndSize` in 3.10) to it that
we need some other ways to do the same thing, so I had to abstract a few
things into macros, and sometimes re-implement functions like
`PyObject_NEW`.
One caveat is that in limited API, `OutputType` (used for replacing
`sys.stdout`) no longer inherits from `PyStdPrinter_Type` which I don't
think has any real issue other than minor differences in how they
convert to a string and missing a couple functions like `mode()` and
`fileno()`.
Also fixed an existing bug where `tp_basicsize` was set incorrectly for
`BufferObject`, `TabListObject, `WinListObject`.
Technically, there could be a small performance drop, there is a little
more indirection with accessing type objects, and some APIs like
`PyUnicode_AsUTF8AndSize` are missing, but in practice I didn't see any
difference, and any well-written Python plugin should try to avoid
excessing callbacks to the `vim` module in Python anyway.
I only tested limited API mode down to Python 3.7, which seemes to
compile and work fine. I haven't tried earlier Python versions.
2) Fix PyIter_Check on older Python vers / type##Ptr unused warning
For PyIter_Check, older versions exposed them as either macros (used in
full API), or a function (for use in limited API). A previous change
exposed PyIter_Check to the dynamic build because Python just moved it
to function-only in 3.10 anyway. Because of that, just make sure we
always grab the function in dynamic builds in earlier versions since
that's what Python eventually did anyway.
3) Move Py_LIMITED_API define to configure script
Can now use --with-python-stable-abi flag to customize what stable ABI
version to target. Can also use an env var to do so as well.
4) Show +python/dyn-stable in :version, and allow has() feature query
Not sure if the "/dyn-stable" suffix would break things, or whether we
should do it another way. Or just don't show it in version and rely on
has() feature checking.
5) Documentation first draft. Still need to implement v:python3_version
6) Fix PyIter_Check build breaks when compiling against Python 3.8
7) Add CI coverage stable ABI on Linux/Windows / make configurable on Windows
This adds configurable options for Windows make files (both MinGW and
MSVC). CI will also now exercise both traditional full API and stable
ABI for Linux and Windows in the matrix for coverage.
Also added a "dynamic" option to Linux matrix as a drive-by change to
make other scripting languages like Ruby / Perl testable under both
static and dynamic builds.
8) Fix inaccuracy in Windows docs
Python's own docs are confusing but you don't actually want to use
`python3.dll` for the dynamic linkage.
9) Add generated autoconf file
10) Add v:python3_version support
This variable indicates the version of Python3 that Vim was built
against (PY_VERSION_HEX), and will be useful to check whether the Python
library you are loading in dynamically actually fits it. When built with
stable ABI, it will be the limited ABI version instead
(`Py_LIMITED_API`), which indicates the minimum version of Python 3 the
user should have, rather than the exact match. When stable ABI is used,
we won't be exposing PY_VERSION_HEX in this var because it just doesn't
seem necessary to do so (the whole point of stable ABI is the promise
that it will work across versions), and I don't want to confuse the user
with too many variables.
Also, cleaned up some documentation, and added help tags.
11) Fix Python 3.7 compat issues
Fix a couple issues when using limited API < 3.8
- Crash on exit: In Python 3.7, if a heap-allocated type is destroyed
before all instances are, it would cause a crash later. This happens
when we destroyed `OptionsType` before calling `Py_Finalize` when
using the limited API. To make it worse, later versions changed the
semantics and now each instance has a strong reference to its own type
and the recommendation has changed to have each instance de-ref its
own type and have its type in GC traversal. To avoid dealing with
these cross-version variations, we just don't free the heap type. They
are static types in non-limited-API anyway and are designed to last
through the entirety of the app, and we also don't restart the Python
runtime and therefore do not need it to have absolutely 0 leaks.
See:
- https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-c-api
- https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api
- PyIter_Check: This function is not provided in limited APIs older than
3.8. Previously I was trying to mock it out using manual
PyType_GetSlot() but it was brittle and also does not actually work
properly for static types (it will generate a Python error). Just
return false. It does mean using limited API < 3.8 is not recommended
as you lose the functionality to handle iterators, but from playing
with plugins I couldn't find it to be an issue.
- Fix loading of PyIter_Check so it will be done when limited API < 3.8.
Otherwise loading a 3.7 Python lib will fail even if limited API was
specified to use it.
12) Make sure to only load `PyUnicode_AsUTF8AndSize` in needed in limited API
We don't use this function unless limited API >= 3.10, but we were
loading it regardless. Usually it's ok in Unix-like systems where Python
just has a single lib that we load from, but in Windows where there is a
separate python3.dll this would not work as the symbol would not have
been exposed in this more limited DLL file. This makes it much clearer
under what condition is this function needed.
closes: #12032
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
2023-08-20 21:18:38 +02:00
|
|
|
# if (defined(USE_LIMITED_API) && Py_LIMITED_API >= 0x03080000) || \
|
|
|
|
(!defined(USE_LIMITED_API) && PY_VERSION_HEX >= 0x03080000)
|
2021-06-14 15:08:30 +02:00
|
|
|
static int (*py3_PyIter_Check)(PyObject *o);
|
|
|
|
# endif
|
2012-06-29 12:54:53 +02:00
|
|
|
static PyObject* (*py3_PyIter_Next)(PyObject *);
|
|
|
|
static PyObject* (*py3_PyObject_GetIter)(PyObject *);
|
2013-06-23 14:16:57 +02:00
|
|
|
static PyObject* (*py3_PyObject_Repr)(PyObject *);
|
2013-05-30 13:22:13 +02:00
|
|
|
static PyObject* (*py3_PyObject_GetItem)(PyObject *, PyObject *);
|
2013-05-15 14:51:35 +02:00
|
|
|
static int (*py3_PyObject_IsTrue)(PyObject *);
|
2010-07-17 21:19:38 +02:00
|
|
|
static PyObject* (*py3_Py_BuildValue)(char *, ...);
|
patch 9.0.1776: No support for stable Python 3 ABI
Problem: No support for stable Python 3 ABI
Solution: Support Python 3 stable ABI
Commits:
1) Support Python 3 stable ABI to allow mixed version interoperatbility
Vim currently supports embedding Python for use with plugins, and the
"dynamic" linking option allows the user to specify a locally installed
version of Python by setting `pythonthreedll`. However, one caveat is
that the Python 3 libs are not binary compatible across minor versions,
and mixing versions can potentially be dangerous (e.g. let's say Vim was
linked against the Python 3.10 SDK, but the user sets `pythonthreedll`
to a 3.11 lib). Usually, nothing bad happens, but in theory this could
lead to crashes, memory corruption, and other unpredictable behaviors.
It's also difficult for the user to tell something is wrong because Vim
has no way of reporting what Python 3 version Vim was linked with.
For Vim installed via a package manager, this usually isn't an issue
because all the dependencies would already be figured out. For prebuilt
Vim binaries like MacVim (my motivation for working on this), AppImage,
and Win32 installer this could potentially be an issue as usually a
single binary is distributed. This is more tricky when a new Python
version is released, as there's a chicken-and-egg issue with deciding
what Python version to build against and hard to keep in sync when a new
Python version just drops and we have a mix of users of different Python
versions, and a user just blindly upgrading to a new Python could lead to
bad interactions with Vim.
Python 3 does have a solution for this problem: stable ABI / limited API
(see https://docs.python.org/3/c-api/stable.html). The C SDK limits the
API to a set of functions that are promised to be stable across
versions. This pull request adds an ifdef config that allows us to turn
it on when building Vim. Vim binaries built with this option should be
safe to freely link with any Python 3 libraies without having the
constraint of having to use the same minor version.
Note: Python 2 has no such concept and this doesn't change how Python 2
integration works (not that there is going to be a new version of Python
2 that would cause compatibility issues in the future anyway).
---
Technical details:
======
The stable ABI can be accessed when we compile with the Python 3 limited
API (by defining `Py_LIMITED_API`). The Python 3 code (in `if_python3.c`
and `if_py_both.h`) would now handle this and switch to limited API
mode. Without it set, Vim will still use the full API as before so this
is an opt-in change.
The main difference is that `PyType_Object` is now an opaque struct that
we can't directly create "static types" out of, and we have to create
type objects as "heap types" instead. This is because the struct is not
stable and changes from version to version (e.g. 3.8 added a
`tp_vectorcall` field to it). I had to change all the types to be
allocated on the heap instead with just a pointer to them.
Other functions are also simply missing in limited API, or they are
introduced too late (e.g. `PyUnicode_AsUTF8AndSize` in 3.10) to it that
we need some other ways to do the same thing, so I had to abstract a few
things into macros, and sometimes re-implement functions like
`PyObject_NEW`.
One caveat is that in limited API, `OutputType` (used for replacing
`sys.stdout`) no longer inherits from `PyStdPrinter_Type` which I don't
think has any real issue other than minor differences in how they
convert to a string and missing a couple functions like `mode()` and
`fileno()`.
Also fixed an existing bug where `tp_basicsize` was set incorrectly for
`BufferObject`, `TabListObject, `WinListObject`.
Technically, there could be a small performance drop, there is a little
more indirection with accessing type objects, and some APIs like
`PyUnicode_AsUTF8AndSize` are missing, but in practice I didn't see any
difference, and any well-written Python plugin should try to avoid
excessing callbacks to the `vim` module in Python anyway.
I only tested limited API mode down to Python 3.7, which seemes to
compile and work fine. I haven't tried earlier Python versions.
2) Fix PyIter_Check on older Python vers / type##Ptr unused warning
For PyIter_Check, older versions exposed them as either macros (used in
full API), or a function (for use in limited API). A previous change
exposed PyIter_Check to the dynamic build because Python just moved it
to function-only in 3.10 anyway. Because of that, just make sure we
always grab the function in dynamic builds in earlier versions since
that's what Python eventually did anyway.
3) Move Py_LIMITED_API define to configure script
Can now use --with-python-stable-abi flag to customize what stable ABI
version to target. Can also use an env var to do so as well.
4) Show +python/dyn-stable in :version, and allow has() feature query
Not sure if the "/dyn-stable" suffix would break things, or whether we
should do it another way. Or just don't show it in version and rely on
has() feature checking.
5) Documentation first draft. Still need to implement v:python3_version
6) Fix PyIter_Check build breaks when compiling against Python 3.8
7) Add CI coverage stable ABI on Linux/Windows / make configurable on Windows
This adds configurable options for Windows make files (both MinGW and
MSVC). CI will also now exercise both traditional full API and stable
ABI for Linux and Windows in the matrix for coverage.
Also added a "dynamic" option to Linux matrix as a drive-by change to
make other scripting languages like Ruby / Perl testable under both
static and dynamic builds.
8) Fix inaccuracy in Windows docs
Python's own docs are confusing but you don't actually want to use
`python3.dll` for the dynamic linkage.
9) Add generated autoconf file
10) Add v:python3_version support
This variable indicates the version of Python3 that Vim was built
against (PY_VERSION_HEX), and will be useful to check whether the Python
library you are loading in dynamically actually fits it. When built with
stable ABI, it will be the limited ABI version instead
(`Py_LIMITED_API`), which indicates the minimum version of Python 3 the
user should have, rather than the exact match. When stable ABI is used,
we won't be exposing PY_VERSION_HEX in this var because it just doesn't
seem necessary to do so (the whole point of stable ABI is the promise
that it will work across versions), and I don't want to confuse the user
with too many variables.
Also, cleaned up some documentation, and added help tags.
11) Fix Python 3.7 compat issues
Fix a couple issues when using limited API < 3.8
- Crash on exit: In Python 3.7, if a heap-allocated type is destroyed
before all instances are, it would cause a crash later. This happens
when we destroyed `OptionsType` before calling `Py_Finalize` when
using the limited API. To make it worse, later versions changed the
semantics and now each instance has a strong reference to its own type
and the recommendation has changed to have each instance de-ref its
own type and have its type in GC traversal. To avoid dealing with
these cross-version variations, we just don't free the heap type. They
are static types in non-limited-API anyway and are designed to last
through the entirety of the app, and we also don't restart the Python
runtime and therefore do not need it to have absolutely 0 leaks.
See:
- https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-c-api
- https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api
- PyIter_Check: This function is not provided in limited APIs older than
3.8. Previously I was trying to mock it out using manual
PyType_GetSlot() but it was brittle and also does not actually work
properly for static types (it will generate a Python error). Just
return false. It does mean using limited API < 3.8 is not recommended
as you lose the functionality to handle iterators, but from playing
with plugins I couldn't find it to be an issue.
- Fix loading of PyIter_Check so it will be done when limited API < 3.8.
Otherwise loading a 3.7 Python lib will fail even if limited API was
specified to use it.
12) Make sure to only load `PyUnicode_AsUTF8AndSize` in needed in limited API
We don't use this function unless limited API >= 3.10, but we were
loading it regardless. Usually it's ok in Unix-like systems where Python
just has a single lib that we load from, but in Windows where there is a
separate python3.dll this would not work as the symbol would not have
been exposed in this more limited DLL file. This makes it much clearer
under what condition is this function needed.
closes: #12032
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
2023-08-20 21:18:38 +02:00
|
|
|
# if PY_VERSION_HEX >= 0x03040000
|
2020-07-16 22:15:53 +02:00
|
|
|
static int (*py3_PyType_GetFlags)(PyTypeObject *o);
|
|
|
|
# endif
|
2010-07-17 21:19:38 +02:00
|
|
|
static int (*py3_PyType_Ready)(PyTypeObject *type);
|
|
|
|
static int (*py3_PyDict_SetItemString)(PyObject *dp, char *key, PyObject *item);
|
|
|
|
static PyObject* (*py3_PyUnicode_FromString)(const char *u);
|
2023-10-11 21:27:06 +02:00
|
|
|
# ifdef Py_UNICODE_USE_UCS_FUNCTIONS
|
2013-05-30 12:40:39 +02:00
|
|
|
# ifdef Py_UNICODE_WIDE
|
|
|
|
static PyObject* (*py3_PyUnicodeUCS4_FromFormat)(const char *u, ...);
|
|
|
|
# else
|
|
|
|
static PyObject* (*py3_PyUnicodeUCS2_FromFormat)(const char *u, ...);
|
|
|
|
# endif
|
2023-10-11 21:27:06 +02:00
|
|
|
# else
|
|
|
|
static PyObject* (*py3_PyUnicode_FromFormat)(const char *u, ...);
|
2013-05-30 12:40:39 +02:00
|
|
|
# endif
|
2011-06-19 00:27:51 +02:00
|
|
|
static PyObject* (*py3_PyUnicode_Decode)(const char *u, Py_ssize_t size,
|
|
|
|
const char *encoding, const char *errors);
|
2010-07-17 21:19:38 +02:00
|
|
|
static long (*py3_PyLong_AsLong)(PyObject *);
|
|
|
|
static void (*py3_PyErr_SetNone)(PyObject *);
|
|
|
|
static void (*py3_PyEval_InitThreads)(void);
|
|
|
|
static void(*py3_PyEval_RestoreThread)(PyThreadState *);
|
|
|
|
static PyThreadState*(*py3_PyEval_SaveThread)(void);
|
|
|
|
static int (*py3_PyArg_Parse)(PyObject *, char *, ...);
|
|
|
|
static int (*py3_PyArg_ParseTuple)(PyObject *, char *, ...);
|
2023-09-20 19:59:47 +02:00
|
|
|
static void (*py3_PyMem_Free)(void *);
|
2012-06-29 12:54:53 +02:00
|
|
|
static void* (*py3_PyMem_Malloc)(size_t);
|
2010-07-17 21:19:38 +02:00
|
|
|
static int (*py3_Py_IsInitialized)(void);
|
|
|
|
static void (*py3_PyErr_Clear)(void);
|
2013-06-23 13:46:40 +02:00
|
|
|
static PyObject* (*py3_PyErr_Format)(PyObject *, const char *, ...);
|
2013-02-20 16:09:43 +01:00
|
|
|
static void (*py3_PyErr_PrintEx)(int);
|
2010-07-17 21:19:38 +02:00
|
|
|
static PyObject*(*py3__PyObject_Init)(PyObject *, PyTypeObject *);
|
2024-09-09 19:46:17 +02:00
|
|
|
# if !defined(USE_LIMITED_API) && PY_VERSION_HEX < 0x030D0000
|
2012-06-29 12:54:53 +02:00
|
|
|
static iternextfunc py3__PyObject_NextNotImplemented;
|
2023-10-04 20:05:05 +02:00
|
|
|
# endif
|
2010-07-17 21:19:38 +02:00
|
|
|
static PyObject* py3__Py_NoneStruct;
|
2012-09-21 14:00:35 +02:00
|
|
|
static PyObject* py3__Py_FalseStruct;
|
|
|
|
static PyObject* py3__Py_TrueStruct;
|
2010-07-17 21:19:38 +02:00
|
|
|
static int (*py3_PyModule_AddObject)(PyObject *m, const char *name, PyObject *o);
|
|
|
|
static int (*py3_PyImport_AppendInittab)(const char *name, PyObject* (*initfunc)(void));
|
patch 9.0.1776: No support for stable Python 3 ABI
Problem: No support for stable Python 3 ABI
Solution: Support Python 3 stable ABI
Commits:
1) Support Python 3 stable ABI to allow mixed version interoperatbility
Vim currently supports embedding Python for use with plugins, and the
"dynamic" linking option allows the user to specify a locally installed
version of Python by setting `pythonthreedll`. However, one caveat is
that the Python 3 libs are not binary compatible across minor versions,
and mixing versions can potentially be dangerous (e.g. let's say Vim was
linked against the Python 3.10 SDK, but the user sets `pythonthreedll`
to a 3.11 lib). Usually, nothing bad happens, but in theory this could
lead to crashes, memory corruption, and other unpredictable behaviors.
It's also difficult for the user to tell something is wrong because Vim
has no way of reporting what Python 3 version Vim was linked with.
For Vim installed via a package manager, this usually isn't an issue
because all the dependencies would already be figured out. For prebuilt
Vim binaries like MacVim (my motivation for working on this), AppImage,
and Win32 installer this could potentially be an issue as usually a
single binary is distributed. This is more tricky when a new Python
version is released, as there's a chicken-and-egg issue with deciding
what Python version to build against and hard to keep in sync when a new
Python version just drops and we have a mix of users of different Python
versions, and a user just blindly upgrading to a new Python could lead to
bad interactions with Vim.
Python 3 does have a solution for this problem: stable ABI / limited API
(see https://docs.python.org/3/c-api/stable.html). The C SDK limits the
API to a set of functions that are promised to be stable across
versions. This pull request adds an ifdef config that allows us to turn
it on when building Vim. Vim binaries built with this option should be
safe to freely link with any Python 3 libraies without having the
constraint of having to use the same minor version.
Note: Python 2 has no such concept and this doesn't change how Python 2
integration works (not that there is going to be a new version of Python
2 that would cause compatibility issues in the future anyway).
---
Technical details:
======
The stable ABI can be accessed when we compile with the Python 3 limited
API (by defining `Py_LIMITED_API`). The Python 3 code (in `if_python3.c`
and `if_py_both.h`) would now handle this and switch to limited API
mode. Without it set, Vim will still use the full API as before so this
is an opt-in change.
The main difference is that `PyType_Object` is now an opaque struct that
we can't directly create "static types" out of, and we have to create
type objects as "heap types" instead. This is because the struct is not
stable and changes from version to version (e.g. 3.8 added a
`tp_vectorcall` field to it). I had to change all the types to be
allocated on the heap instead with just a pointer to them.
Other functions are also simply missing in limited API, or they are
introduced too late (e.g. `PyUnicode_AsUTF8AndSize` in 3.10) to it that
we need some other ways to do the same thing, so I had to abstract a few
things into macros, and sometimes re-implement functions like
`PyObject_NEW`.
One caveat is that in limited API, `OutputType` (used for replacing
`sys.stdout`) no longer inherits from `PyStdPrinter_Type` which I don't
think has any real issue other than minor differences in how they
convert to a string and missing a couple functions like `mode()` and
`fileno()`.
Also fixed an existing bug where `tp_basicsize` was set incorrectly for
`BufferObject`, `TabListObject, `WinListObject`.
Technically, there could be a small performance drop, there is a little
more indirection with accessing type objects, and some APIs like
`PyUnicode_AsUTF8AndSize` are missing, but in practice I didn't see any
difference, and any well-written Python plugin should try to avoid
excessing callbacks to the `vim` module in Python anyway.
I only tested limited API mode down to Python 3.7, which seemes to
compile and work fine. I haven't tried earlier Python versions.
2) Fix PyIter_Check on older Python vers / type##Ptr unused warning
For PyIter_Check, older versions exposed them as either macros (used in
full API), or a function (for use in limited API). A previous change
exposed PyIter_Check to the dynamic build because Python just moved it
to function-only in 3.10 anyway. Because of that, just make sure we
always grab the function in dynamic builds in earlier versions since
that's what Python eventually did anyway.
3) Move Py_LIMITED_API define to configure script
Can now use --with-python-stable-abi flag to customize what stable ABI
version to target. Can also use an env var to do so as well.
4) Show +python/dyn-stable in :version, and allow has() feature query
Not sure if the "/dyn-stable" suffix would break things, or whether we
should do it another way. Or just don't show it in version and rely on
has() feature checking.
5) Documentation first draft. Still need to implement v:python3_version
6) Fix PyIter_Check build breaks when compiling against Python 3.8
7) Add CI coverage stable ABI on Linux/Windows / make configurable on Windows
This adds configurable options for Windows make files (both MinGW and
MSVC). CI will also now exercise both traditional full API and stable
ABI for Linux and Windows in the matrix for coverage.
Also added a "dynamic" option to Linux matrix as a drive-by change to
make other scripting languages like Ruby / Perl testable under both
static and dynamic builds.
8) Fix inaccuracy in Windows docs
Python's own docs are confusing but you don't actually want to use
`python3.dll` for the dynamic linkage.
9) Add generated autoconf file
10) Add v:python3_version support
This variable indicates the version of Python3 that Vim was built
against (PY_VERSION_HEX), and will be useful to check whether the Python
library you are loading in dynamically actually fits it. When built with
stable ABI, it will be the limited ABI version instead
(`Py_LIMITED_API`), which indicates the minimum version of Python 3 the
user should have, rather than the exact match. When stable ABI is used,
we won't be exposing PY_VERSION_HEX in this var because it just doesn't
seem necessary to do so (the whole point of stable ABI is the promise
that it will work across versions), and I don't want to confuse the user
with too many variables.
Also, cleaned up some documentation, and added help tags.
11) Fix Python 3.7 compat issues
Fix a couple issues when using limited API < 3.8
- Crash on exit: In Python 3.7, if a heap-allocated type is destroyed
before all instances are, it would cause a crash later. This happens
when we destroyed `OptionsType` before calling `Py_Finalize` when
using the limited API. To make it worse, later versions changed the
semantics and now each instance has a strong reference to its own type
and the recommendation has changed to have each instance de-ref its
own type and have its type in GC traversal. To avoid dealing with
these cross-version variations, we just don't free the heap type. They
are static types in non-limited-API anyway and are designed to last
through the entirety of the app, and we also don't restart the Python
runtime and therefore do not need it to have absolutely 0 leaks.
See:
- https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-c-api
- https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api
- PyIter_Check: This function is not provided in limited APIs older than
3.8. Previously I was trying to mock it out using manual
PyType_GetSlot() but it was brittle and also does not actually work
properly for static types (it will generate a Python error). Just
return false. It does mean using limited API < 3.8 is not recommended
as you lose the functionality to handle iterators, but from playing
with plugins I couldn't find it to be an issue.
- Fix loading of PyIter_Check so it will be done when limited API < 3.8.
Otherwise loading a 3.7 Python lib will fail even if limited API was
specified to use it.
12) Make sure to only load `PyUnicode_AsUTF8AndSize` in needed in limited API
We don't use this function unless limited API >= 3.10, but we were
loading it regardless. Usually it's ok in Unix-like systems where Python
just has a single lib that we load from, but in Windows where there is a
separate python3.dll this would not work as the symbol would not have
been exposed in this more limited DLL file. This makes it much clearer
under what condition is this function needed.
closes: #12032
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
2023-08-20 21:18:38 +02:00
|
|
|
# ifdef USE_LIMITED_API
|
|
|
|
# if Py_LIMITED_API >= 0x030a0000
|
|
|
|
static char* (*py3_PyUnicode_AsUTF8AndSize)(PyObject *unicode, Py_ssize_t *size);
|
|
|
|
# endif
|
2012-10-23 05:17:37 +02:00
|
|
|
# else
|
patch 9.0.1776: No support for stable Python 3 ABI
Problem: No support for stable Python 3 ABI
Solution: Support Python 3 stable ABI
Commits:
1) Support Python 3 stable ABI to allow mixed version interoperatbility
Vim currently supports embedding Python for use with plugins, and the
"dynamic" linking option allows the user to specify a locally installed
version of Python by setting `pythonthreedll`. However, one caveat is
that the Python 3 libs are not binary compatible across minor versions,
and mixing versions can potentially be dangerous (e.g. let's say Vim was
linked against the Python 3.10 SDK, but the user sets `pythonthreedll`
to a 3.11 lib). Usually, nothing bad happens, but in theory this could
lead to crashes, memory corruption, and other unpredictable behaviors.
It's also difficult for the user to tell something is wrong because Vim
has no way of reporting what Python 3 version Vim was linked with.
For Vim installed via a package manager, this usually isn't an issue
because all the dependencies would already be figured out. For prebuilt
Vim binaries like MacVim (my motivation for working on this), AppImage,
and Win32 installer this could potentially be an issue as usually a
single binary is distributed. This is more tricky when a new Python
version is released, as there's a chicken-and-egg issue with deciding
what Python version to build against and hard to keep in sync when a new
Python version just drops and we have a mix of users of different Python
versions, and a user just blindly upgrading to a new Python could lead to
bad interactions with Vim.
Python 3 does have a solution for this problem: stable ABI / limited API
(see https://docs.python.org/3/c-api/stable.html). The C SDK limits the
API to a set of functions that are promised to be stable across
versions. This pull request adds an ifdef config that allows us to turn
it on when building Vim. Vim binaries built with this option should be
safe to freely link with any Python 3 libraies without having the
constraint of having to use the same minor version.
Note: Python 2 has no such concept and this doesn't change how Python 2
integration works (not that there is going to be a new version of Python
2 that would cause compatibility issues in the future anyway).
---
Technical details:
======
The stable ABI can be accessed when we compile with the Python 3 limited
API (by defining `Py_LIMITED_API`). The Python 3 code (in `if_python3.c`
and `if_py_both.h`) would now handle this and switch to limited API
mode. Without it set, Vim will still use the full API as before so this
is an opt-in change.
The main difference is that `PyType_Object` is now an opaque struct that
we can't directly create "static types" out of, and we have to create
type objects as "heap types" instead. This is because the struct is not
stable and changes from version to version (e.g. 3.8 added a
`tp_vectorcall` field to it). I had to change all the types to be
allocated on the heap instead with just a pointer to them.
Other functions are also simply missing in limited API, or they are
introduced too late (e.g. `PyUnicode_AsUTF8AndSize` in 3.10) to it that
we need some other ways to do the same thing, so I had to abstract a few
things into macros, and sometimes re-implement functions like
`PyObject_NEW`.
One caveat is that in limited API, `OutputType` (used for replacing
`sys.stdout`) no longer inherits from `PyStdPrinter_Type` which I don't
think has any real issue other than minor differences in how they
convert to a string and missing a couple functions like `mode()` and
`fileno()`.
Also fixed an existing bug where `tp_basicsize` was set incorrectly for
`BufferObject`, `TabListObject, `WinListObject`.
Technically, there could be a small performance drop, there is a little
more indirection with accessing type objects, and some APIs like
`PyUnicode_AsUTF8AndSize` are missing, but in practice I didn't see any
difference, and any well-written Python plugin should try to avoid
excessing callbacks to the `vim` module in Python anyway.
I only tested limited API mode down to Python 3.7, which seemes to
compile and work fine. I haven't tried earlier Python versions.
2) Fix PyIter_Check on older Python vers / type##Ptr unused warning
For PyIter_Check, older versions exposed them as either macros (used in
full API), or a function (for use in limited API). A previous change
exposed PyIter_Check to the dynamic build because Python just moved it
to function-only in 3.10 anyway. Because of that, just make sure we
always grab the function in dynamic builds in earlier versions since
that's what Python eventually did anyway.
3) Move Py_LIMITED_API define to configure script
Can now use --with-python-stable-abi flag to customize what stable ABI
version to target. Can also use an env var to do so as well.
4) Show +python/dyn-stable in :version, and allow has() feature query
Not sure if the "/dyn-stable" suffix would break things, or whether we
should do it another way. Or just don't show it in version and rely on
has() feature checking.
5) Documentation first draft. Still need to implement v:python3_version
6) Fix PyIter_Check build breaks when compiling against Python 3.8
7) Add CI coverage stable ABI on Linux/Windows / make configurable on Windows
This adds configurable options for Windows make files (both MinGW and
MSVC). CI will also now exercise both traditional full API and stable
ABI for Linux and Windows in the matrix for coverage.
Also added a "dynamic" option to Linux matrix as a drive-by change to
make other scripting languages like Ruby / Perl testable under both
static and dynamic builds.
8) Fix inaccuracy in Windows docs
Python's own docs are confusing but you don't actually want to use
`python3.dll` for the dynamic linkage.
9) Add generated autoconf file
10) Add v:python3_version support
This variable indicates the version of Python3 that Vim was built
against (PY_VERSION_HEX), and will be useful to check whether the Python
library you are loading in dynamically actually fits it. When built with
stable ABI, it will be the limited ABI version instead
(`Py_LIMITED_API`), which indicates the minimum version of Python 3 the
user should have, rather than the exact match. When stable ABI is used,
we won't be exposing PY_VERSION_HEX in this var because it just doesn't
seem necessary to do so (the whole point of stable ABI is the promise
that it will work across versions), and I don't want to confuse the user
with too many variables.
Also, cleaned up some documentation, and added help tags.
11) Fix Python 3.7 compat issues
Fix a couple issues when using limited API < 3.8
- Crash on exit: In Python 3.7, if a heap-allocated type is destroyed
before all instances are, it would cause a crash later. This happens
when we destroyed `OptionsType` before calling `Py_Finalize` when
using the limited API. To make it worse, later versions changed the
semantics and now each instance has a strong reference to its own type
and the recommendation has changed to have each instance de-ref its
own type and have its type in GC traversal. To avoid dealing with
these cross-version variations, we just don't free the heap type. They
are static types in non-limited-API anyway and are designed to last
through the entirety of the app, and we also don't restart the Python
runtime and therefore do not need it to have absolutely 0 leaks.
See:
- https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-c-api
- https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api
- PyIter_Check: This function is not provided in limited APIs older than
3.8. Previously I was trying to mock it out using manual
PyType_GetSlot() but it was brittle and also does not actually work
properly for static types (it will generate a Python error). Just
return false. It does mean using limited API < 3.8 is not recommended
as you lose the functionality to handle iterators, but from playing
with plugins I couldn't find it to be an issue.
- Fix loading of PyIter_Check so it will be done when limited API < 3.8.
Otherwise loading a 3.7 Python lib will fail even if limited API was
specified to use it.
12) Make sure to only load `PyUnicode_AsUTF8AndSize` in needed in limited API
We don't use this function unless limited API >= 3.10, but we were
loading it regardless. Usually it's ok in Unix-like systems where Python
just has a single lib that we load from, but in Windows where there is a
separate python3.dll this would not work as the symbol would not have
been exposed in this more limited DLL file. This makes it much clearer
under what condition is this function needed.
closes: #12032
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
2023-08-20 21:18:38 +02:00
|
|
|
# if PY_VERSION_HEX >= 0x030300f0
|
|
|
|
static char* (*py3_PyUnicode_AsUTF8AndSize)(PyObject *unicode, Py_ssize_t *size);
|
|
|
|
# else
|
2010-07-17 21:19:38 +02:00
|
|
|
static char* (*py3__PyUnicode_AsString)(PyObject *unicode);
|
patch 9.0.1776: No support for stable Python 3 ABI
Problem: No support for stable Python 3 ABI
Solution: Support Python 3 stable ABI
Commits:
1) Support Python 3 stable ABI to allow mixed version interoperatbility
Vim currently supports embedding Python for use with plugins, and the
"dynamic" linking option allows the user to specify a locally installed
version of Python by setting `pythonthreedll`. However, one caveat is
that the Python 3 libs are not binary compatible across minor versions,
and mixing versions can potentially be dangerous (e.g. let's say Vim was
linked against the Python 3.10 SDK, but the user sets `pythonthreedll`
to a 3.11 lib). Usually, nothing bad happens, but in theory this could
lead to crashes, memory corruption, and other unpredictable behaviors.
It's also difficult for the user to tell something is wrong because Vim
has no way of reporting what Python 3 version Vim was linked with.
For Vim installed via a package manager, this usually isn't an issue
because all the dependencies would already be figured out. For prebuilt
Vim binaries like MacVim (my motivation for working on this), AppImage,
and Win32 installer this could potentially be an issue as usually a
single binary is distributed. This is more tricky when a new Python
version is released, as there's a chicken-and-egg issue with deciding
what Python version to build against and hard to keep in sync when a new
Python version just drops and we have a mix of users of different Python
versions, and a user just blindly upgrading to a new Python could lead to
bad interactions with Vim.
Python 3 does have a solution for this problem: stable ABI / limited API
(see https://docs.python.org/3/c-api/stable.html). The C SDK limits the
API to a set of functions that are promised to be stable across
versions. This pull request adds an ifdef config that allows us to turn
it on when building Vim. Vim binaries built with this option should be
safe to freely link with any Python 3 libraies without having the
constraint of having to use the same minor version.
Note: Python 2 has no such concept and this doesn't change how Python 2
integration works (not that there is going to be a new version of Python
2 that would cause compatibility issues in the future anyway).
---
Technical details:
======
The stable ABI can be accessed when we compile with the Python 3 limited
API (by defining `Py_LIMITED_API`). The Python 3 code (in `if_python3.c`
and `if_py_both.h`) would now handle this and switch to limited API
mode. Without it set, Vim will still use the full API as before so this
is an opt-in change.
The main difference is that `PyType_Object` is now an opaque struct that
we can't directly create "static types" out of, and we have to create
type objects as "heap types" instead. This is because the struct is not
stable and changes from version to version (e.g. 3.8 added a
`tp_vectorcall` field to it). I had to change all the types to be
allocated on the heap instead with just a pointer to them.
Other functions are also simply missing in limited API, or they are
introduced too late (e.g. `PyUnicode_AsUTF8AndSize` in 3.10) to it that
we need some other ways to do the same thing, so I had to abstract a few
things into macros, and sometimes re-implement functions like
`PyObject_NEW`.
One caveat is that in limited API, `OutputType` (used for replacing
`sys.stdout`) no longer inherits from `PyStdPrinter_Type` which I don't
think has any real issue other than minor differences in how they
convert to a string and missing a couple functions like `mode()` and
`fileno()`.
Also fixed an existing bug where `tp_basicsize` was set incorrectly for
`BufferObject`, `TabListObject, `WinListObject`.
Technically, there could be a small performance drop, there is a little
more indirection with accessing type objects, and some APIs like
`PyUnicode_AsUTF8AndSize` are missing, but in practice I didn't see any
difference, and any well-written Python plugin should try to avoid
excessing callbacks to the `vim` module in Python anyway.
I only tested limited API mode down to Python 3.7, which seemes to
compile and work fine. I haven't tried earlier Python versions.
2) Fix PyIter_Check on older Python vers / type##Ptr unused warning
For PyIter_Check, older versions exposed them as either macros (used in
full API), or a function (for use in limited API). A previous change
exposed PyIter_Check to the dynamic build because Python just moved it
to function-only in 3.10 anyway. Because of that, just make sure we
always grab the function in dynamic builds in earlier versions since
that's what Python eventually did anyway.
3) Move Py_LIMITED_API define to configure script
Can now use --with-python-stable-abi flag to customize what stable ABI
version to target. Can also use an env var to do so as well.
4) Show +python/dyn-stable in :version, and allow has() feature query
Not sure if the "/dyn-stable" suffix would break things, or whether we
should do it another way. Or just don't show it in version and rely on
has() feature checking.
5) Documentation first draft. Still need to implement v:python3_version
6) Fix PyIter_Check build breaks when compiling against Python 3.8
7) Add CI coverage stable ABI on Linux/Windows / make configurable on Windows
This adds configurable options for Windows make files (both MinGW and
MSVC). CI will also now exercise both traditional full API and stable
ABI for Linux and Windows in the matrix for coverage.
Also added a "dynamic" option to Linux matrix as a drive-by change to
make other scripting languages like Ruby / Perl testable under both
static and dynamic builds.
8) Fix inaccuracy in Windows docs
Python's own docs are confusing but you don't actually want to use
`python3.dll` for the dynamic linkage.
9) Add generated autoconf file
10) Add v:python3_version support
This variable indicates the version of Python3 that Vim was built
against (PY_VERSION_HEX), and will be useful to check whether the Python
library you are loading in dynamically actually fits it. When built with
stable ABI, it will be the limited ABI version instead
(`Py_LIMITED_API`), which indicates the minimum version of Python 3 the
user should have, rather than the exact match. When stable ABI is used,
we won't be exposing PY_VERSION_HEX in this var because it just doesn't
seem necessary to do so (the whole point of stable ABI is the promise
that it will work across versions), and I don't want to confuse the user
with too many variables.
Also, cleaned up some documentation, and added help tags.
11) Fix Python 3.7 compat issues
Fix a couple issues when using limited API < 3.8
- Crash on exit: In Python 3.7, if a heap-allocated type is destroyed
before all instances are, it would cause a crash later. This happens
when we destroyed `OptionsType` before calling `Py_Finalize` when
using the limited API. To make it worse, later versions changed the
semantics and now each instance has a strong reference to its own type
and the recommendation has changed to have each instance de-ref its
own type and have its type in GC traversal. To avoid dealing with
these cross-version variations, we just don't free the heap type. They
are static types in non-limited-API anyway and are designed to last
through the entirety of the app, and we also don't restart the Python
runtime and therefore do not need it to have absolutely 0 leaks.
See:
- https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-c-api
- https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api
- PyIter_Check: This function is not provided in limited APIs older than
3.8. Previously I was trying to mock it out using manual
PyType_GetSlot() but it was brittle and also does not actually work
properly for static types (it will generate a Python error). Just
return false. It does mean using limited API < 3.8 is not recommended
as you lose the functionality to handle iterators, but from playing
with plugins I couldn't find it to be an issue.
- Fix loading of PyIter_Check so it will be done when limited API < 3.8.
Otherwise loading a 3.7 Python lib will fail even if limited API was
specified to use it.
12) Make sure to only load `PyUnicode_AsUTF8AndSize` in needed in limited API
We don't use this function unless limited API >= 3.10, but we were
loading it regardless. Usually it's ok in Unix-like systems where Python
just has a single lib that we load from, but in Windows where there is a
separate python3.dll this would not work as the symbol would not have
been exposed in this more limited DLL file. This makes it much clearer
under what condition is this function needed.
closes: #12032
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
2023-08-20 21:18:38 +02:00
|
|
|
# endif
|
2012-10-23 05:17:37 +02:00
|
|
|
# endif
|
patch 9.0.1776: No support for stable Python 3 ABI
Problem: No support for stable Python 3 ABI
Solution: Support Python 3 stable ABI
Commits:
1) Support Python 3 stable ABI to allow mixed version interoperatbility
Vim currently supports embedding Python for use with plugins, and the
"dynamic" linking option allows the user to specify a locally installed
version of Python by setting `pythonthreedll`. However, one caveat is
that the Python 3 libs are not binary compatible across minor versions,
and mixing versions can potentially be dangerous (e.g. let's say Vim was
linked against the Python 3.10 SDK, but the user sets `pythonthreedll`
to a 3.11 lib). Usually, nothing bad happens, but in theory this could
lead to crashes, memory corruption, and other unpredictable behaviors.
It's also difficult for the user to tell something is wrong because Vim
has no way of reporting what Python 3 version Vim was linked with.
For Vim installed via a package manager, this usually isn't an issue
because all the dependencies would already be figured out. For prebuilt
Vim binaries like MacVim (my motivation for working on this), AppImage,
and Win32 installer this could potentially be an issue as usually a
single binary is distributed. This is more tricky when a new Python
version is released, as there's a chicken-and-egg issue with deciding
what Python version to build against and hard to keep in sync when a new
Python version just drops and we have a mix of users of different Python
versions, and a user just blindly upgrading to a new Python could lead to
bad interactions with Vim.
Python 3 does have a solution for this problem: stable ABI / limited API
(see https://docs.python.org/3/c-api/stable.html). The C SDK limits the
API to a set of functions that are promised to be stable across
versions. This pull request adds an ifdef config that allows us to turn
it on when building Vim. Vim binaries built with this option should be
safe to freely link with any Python 3 libraies without having the
constraint of having to use the same minor version.
Note: Python 2 has no such concept and this doesn't change how Python 2
integration works (not that there is going to be a new version of Python
2 that would cause compatibility issues in the future anyway).
---
Technical details:
======
The stable ABI can be accessed when we compile with the Python 3 limited
API (by defining `Py_LIMITED_API`). The Python 3 code (in `if_python3.c`
and `if_py_both.h`) would now handle this and switch to limited API
mode. Without it set, Vim will still use the full API as before so this
is an opt-in change.
The main difference is that `PyType_Object` is now an opaque struct that
we can't directly create "static types" out of, and we have to create
type objects as "heap types" instead. This is because the struct is not
stable and changes from version to version (e.g. 3.8 added a
`tp_vectorcall` field to it). I had to change all the types to be
allocated on the heap instead with just a pointer to them.
Other functions are also simply missing in limited API, or they are
introduced too late (e.g. `PyUnicode_AsUTF8AndSize` in 3.10) to it that
we need some other ways to do the same thing, so I had to abstract a few
things into macros, and sometimes re-implement functions like
`PyObject_NEW`.
One caveat is that in limited API, `OutputType` (used for replacing
`sys.stdout`) no longer inherits from `PyStdPrinter_Type` which I don't
think has any real issue other than minor differences in how they
convert to a string and missing a couple functions like `mode()` and
`fileno()`.
Also fixed an existing bug where `tp_basicsize` was set incorrectly for
`BufferObject`, `TabListObject, `WinListObject`.
Technically, there could be a small performance drop, there is a little
more indirection with accessing type objects, and some APIs like
`PyUnicode_AsUTF8AndSize` are missing, but in practice I didn't see any
difference, and any well-written Python plugin should try to avoid
excessing callbacks to the `vim` module in Python anyway.
I only tested limited API mode down to Python 3.7, which seemes to
compile and work fine. I haven't tried earlier Python versions.
2) Fix PyIter_Check on older Python vers / type##Ptr unused warning
For PyIter_Check, older versions exposed them as either macros (used in
full API), or a function (for use in limited API). A previous change
exposed PyIter_Check to the dynamic build because Python just moved it
to function-only in 3.10 anyway. Because of that, just make sure we
always grab the function in dynamic builds in earlier versions since
that's what Python eventually did anyway.
3) Move Py_LIMITED_API define to configure script
Can now use --with-python-stable-abi flag to customize what stable ABI
version to target. Can also use an env var to do so as well.
4) Show +python/dyn-stable in :version, and allow has() feature query
Not sure if the "/dyn-stable" suffix would break things, or whether we
should do it another way. Or just don't show it in version and rely on
has() feature checking.
5) Documentation first draft. Still need to implement v:python3_version
6) Fix PyIter_Check build breaks when compiling against Python 3.8
7) Add CI coverage stable ABI on Linux/Windows / make configurable on Windows
This adds configurable options for Windows make files (both MinGW and
MSVC). CI will also now exercise both traditional full API and stable
ABI for Linux and Windows in the matrix for coverage.
Also added a "dynamic" option to Linux matrix as a drive-by change to
make other scripting languages like Ruby / Perl testable under both
static and dynamic builds.
8) Fix inaccuracy in Windows docs
Python's own docs are confusing but you don't actually want to use
`python3.dll` for the dynamic linkage.
9) Add generated autoconf file
10) Add v:python3_version support
This variable indicates the version of Python3 that Vim was built
against (PY_VERSION_HEX), and will be useful to check whether the Python
library you are loading in dynamically actually fits it. When built with
stable ABI, it will be the limited ABI version instead
(`Py_LIMITED_API`), which indicates the minimum version of Python 3 the
user should have, rather than the exact match. When stable ABI is used,
we won't be exposing PY_VERSION_HEX in this var because it just doesn't
seem necessary to do so (the whole point of stable ABI is the promise
that it will work across versions), and I don't want to confuse the user
with too many variables.
Also, cleaned up some documentation, and added help tags.
11) Fix Python 3.7 compat issues
Fix a couple issues when using limited API < 3.8
- Crash on exit: In Python 3.7, if a heap-allocated type is destroyed
before all instances are, it would cause a crash later. This happens
when we destroyed `OptionsType` before calling `Py_Finalize` when
using the limited API. To make it worse, later versions changed the
semantics and now each instance has a strong reference to its own type
and the recommendation has changed to have each instance de-ref its
own type and have its type in GC traversal. To avoid dealing with
these cross-version variations, we just don't free the heap type. They
are static types in non-limited-API anyway and are designed to last
through the entirety of the app, and we also don't restart the Python
runtime and therefore do not need it to have absolutely 0 leaks.
See:
- https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-c-api
- https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api
- PyIter_Check: This function is not provided in limited APIs older than
3.8. Previously I was trying to mock it out using manual
PyType_GetSlot() but it was brittle and also does not actually work
properly for static types (it will generate a Python error). Just
return false. It does mean using limited API < 3.8 is not recommended
as you lose the functionality to handle iterators, but from playing
with plugins I couldn't find it to be an issue.
- Fix loading of PyIter_Check so it will be done when limited API < 3.8.
Otherwise loading a 3.7 Python lib will fail even if limited API was
specified to use it.
12) Make sure to only load `PyUnicode_AsUTF8AndSize` in needed in limited API
We don't use this function unless limited API >= 3.10, but we were
loading it regardless. Usually it's ok in Unix-like systems where Python
just has a single lib that we load from, but in Windows where there is a
separate python3.dll this would not work as the symbol would not have
been exposed in this more limited DLL file. This makes it much clearer
under what condition is this function needed.
closes: #12032
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
2023-08-20 21:18:38 +02:00
|
|
|
static int (*py3_PyUnicode_CompareWithASCIIString)(PyObject *unicode, const char* string);
|
2011-06-19 00:27:51 +02:00
|
|
|
static PyObject* (*py3_PyUnicode_AsEncodedString)(PyObject *unicode, const char* encoding, const char* errors);
|
patch 9.0.1776: No support for stable Python 3 ABI
Problem: No support for stable Python 3 ABI
Solution: Support Python 3 stable ABI
Commits:
1) Support Python 3 stable ABI to allow mixed version interoperatbility
Vim currently supports embedding Python for use with plugins, and the
"dynamic" linking option allows the user to specify a locally installed
version of Python by setting `pythonthreedll`. However, one caveat is
that the Python 3 libs are not binary compatible across minor versions,
and mixing versions can potentially be dangerous (e.g. let's say Vim was
linked against the Python 3.10 SDK, but the user sets `pythonthreedll`
to a 3.11 lib). Usually, nothing bad happens, but in theory this could
lead to crashes, memory corruption, and other unpredictable behaviors.
It's also difficult for the user to tell something is wrong because Vim
has no way of reporting what Python 3 version Vim was linked with.
For Vim installed via a package manager, this usually isn't an issue
because all the dependencies would already be figured out. For prebuilt
Vim binaries like MacVim (my motivation for working on this), AppImage,
and Win32 installer this could potentially be an issue as usually a
single binary is distributed. This is more tricky when a new Python
version is released, as there's a chicken-and-egg issue with deciding
what Python version to build against and hard to keep in sync when a new
Python version just drops and we have a mix of users of different Python
versions, and a user just blindly upgrading to a new Python could lead to
bad interactions with Vim.
Python 3 does have a solution for this problem: stable ABI / limited API
(see https://docs.python.org/3/c-api/stable.html). The C SDK limits the
API to a set of functions that are promised to be stable across
versions. This pull request adds an ifdef config that allows us to turn
it on when building Vim. Vim binaries built with this option should be
safe to freely link with any Python 3 libraies without having the
constraint of having to use the same minor version.
Note: Python 2 has no such concept and this doesn't change how Python 2
integration works (not that there is going to be a new version of Python
2 that would cause compatibility issues in the future anyway).
---
Technical details:
======
The stable ABI can be accessed when we compile with the Python 3 limited
API (by defining `Py_LIMITED_API`). The Python 3 code (in `if_python3.c`
and `if_py_both.h`) would now handle this and switch to limited API
mode. Without it set, Vim will still use the full API as before so this
is an opt-in change.
The main difference is that `PyType_Object` is now an opaque struct that
we can't directly create "static types" out of, and we have to create
type objects as "heap types" instead. This is because the struct is not
stable and changes from version to version (e.g. 3.8 added a
`tp_vectorcall` field to it). I had to change all the types to be
allocated on the heap instead with just a pointer to them.
Other functions are also simply missing in limited API, or they are
introduced too late (e.g. `PyUnicode_AsUTF8AndSize` in 3.10) to it that
we need some other ways to do the same thing, so I had to abstract a few
things into macros, and sometimes re-implement functions like
`PyObject_NEW`.
One caveat is that in limited API, `OutputType` (used for replacing
`sys.stdout`) no longer inherits from `PyStdPrinter_Type` which I don't
think has any real issue other than minor differences in how they
convert to a string and missing a couple functions like `mode()` and
`fileno()`.
Also fixed an existing bug where `tp_basicsize` was set incorrectly for
`BufferObject`, `TabListObject, `WinListObject`.
Technically, there could be a small performance drop, there is a little
more indirection with accessing type objects, and some APIs like
`PyUnicode_AsUTF8AndSize` are missing, but in practice I didn't see any
difference, and any well-written Python plugin should try to avoid
excessing callbacks to the `vim` module in Python anyway.
I only tested limited API mode down to Python 3.7, which seemes to
compile and work fine. I haven't tried earlier Python versions.
2) Fix PyIter_Check on older Python vers / type##Ptr unused warning
For PyIter_Check, older versions exposed them as either macros (used in
full API), or a function (for use in limited API). A previous change
exposed PyIter_Check to the dynamic build because Python just moved it
to function-only in 3.10 anyway. Because of that, just make sure we
always grab the function in dynamic builds in earlier versions since
that's what Python eventually did anyway.
3) Move Py_LIMITED_API define to configure script
Can now use --with-python-stable-abi flag to customize what stable ABI
version to target. Can also use an env var to do so as well.
4) Show +python/dyn-stable in :version, and allow has() feature query
Not sure if the "/dyn-stable" suffix would break things, or whether we
should do it another way. Or just don't show it in version and rely on
has() feature checking.
5) Documentation first draft. Still need to implement v:python3_version
6) Fix PyIter_Check build breaks when compiling against Python 3.8
7) Add CI coverage stable ABI on Linux/Windows / make configurable on Windows
This adds configurable options for Windows make files (both MinGW and
MSVC). CI will also now exercise both traditional full API and stable
ABI for Linux and Windows in the matrix for coverage.
Also added a "dynamic" option to Linux matrix as a drive-by change to
make other scripting languages like Ruby / Perl testable under both
static and dynamic builds.
8) Fix inaccuracy in Windows docs
Python's own docs are confusing but you don't actually want to use
`python3.dll` for the dynamic linkage.
9) Add generated autoconf file
10) Add v:python3_version support
This variable indicates the version of Python3 that Vim was built
against (PY_VERSION_HEX), and will be useful to check whether the Python
library you are loading in dynamically actually fits it. When built with
stable ABI, it will be the limited ABI version instead
(`Py_LIMITED_API`), which indicates the minimum version of Python 3 the
user should have, rather than the exact match. When stable ABI is used,
we won't be exposing PY_VERSION_HEX in this var because it just doesn't
seem necessary to do so (the whole point of stable ABI is the promise
that it will work across versions), and I don't want to confuse the user
with too many variables.
Also, cleaned up some documentation, and added help tags.
11) Fix Python 3.7 compat issues
Fix a couple issues when using limited API < 3.8
- Crash on exit: In Python 3.7, if a heap-allocated type is destroyed
before all instances are, it would cause a crash later. This happens
when we destroyed `OptionsType` before calling `Py_Finalize` when
using the limited API. To make it worse, later versions changed the
semantics and now each instance has a strong reference to its own type
and the recommendation has changed to have each instance de-ref its
own type and have its type in GC traversal. To avoid dealing with
these cross-version variations, we just don't free the heap type. They
are static types in non-limited-API anyway and are designed to last
through the entirety of the app, and we also don't restart the Python
runtime and therefore do not need it to have absolutely 0 leaks.
See:
- https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-c-api
- https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api
- PyIter_Check: This function is not provided in limited APIs older than
3.8. Previously I was trying to mock it out using manual
PyType_GetSlot() but it was brittle and also does not actually work
properly for static types (it will generate a Python error). Just
return false. It does mean using limited API < 3.8 is not recommended
as you lose the functionality to handle iterators, but from playing
with plugins I couldn't find it to be an issue.
- Fix loading of PyIter_Check so it will be done when limited API < 3.8.
Otherwise loading a 3.7 Python lib will fail even if limited API was
specified to use it.
12) Make sure to only load `PyUnicode_AsUTF8AndSize` in needed in limited API
We don't use this function unless limited API >= 3.10, but we were
loading it regardless. Usually it's ok in Unix-like systems where Python
just has a single lib that we load from, but in Windows where there is a
separate python3.dll this would not work as the symbol would not have
been exposed in this more limited DLL file. This makes it much clearer
under what condition is this function needed.
closes: #12032
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
2023-08-20 21:18:38 +02:00
|
|
|
static PyObject* (*py3_PyUnicode_AsUTF8String)(PyObject *unicode);
|
2011-06-19 00:27:51 +02:00
|
|
|
static char* (*py3_PyBytes_AsString)(PyObject *bytes);
|
2013-06-23 13:11:18 +02:00
|
|
|
static int (*py3_PyBytes_AsStringAndSize)(PyObject *bytes, char **buffer, Py_ssize_t *length);
|
2012-06-29 12:54:53 +02:00
|
|
|
static PyObject* (*py3_PyBytes_FromString)(char *str);
|
2019-01-12 22:47:31 +01:00
|
|
|
static PyObject* (*py3_PyBytes_FromStringAndSize)(char *str, Py_ssize_t length);
|
2020-07-16 22:15:53 +02:00
|
|
|
# if PY_VERSION_HEX >= 0x030900b0
|
|
|
|
static PyObject* (*py3__PyObject_New)(PyTypeObject *);
|
|
|
|
# endif
|
2012-06-29 12:54:53 +02:00
|
|
|
static PyObject* (*py3_PyFloat_FromDouble)(double num);
|
|
|
|
static double (*py3_PyFloat_AsDouble)(PyObject *);
|
2010-07-17 21:19:38 +02:00
|
|
|
static PyObject* (*py3_PyObject_GenericGetAttr)(PyObject *obj, PyObject *name);
|
|
|
|
static PyObject* (*py3_PyType_GenericAlloc)(PyTypeObject *type, Py_ssize_t nitems);
|
|
|
|
static PyObject* (*py3_PyType_GenericNew)(PyTypeObject *type, PyObject *args, PyObject *kwds);
|
2012-09-21 14:00:35 +02:00
|
|
|
static PyTypeObject* py3_PyType_Type;
|
2023-10-04 20:05:05 +02:00
|
|
|
# ifndef USE_LIMITED_API
|
2018-05-15 22:31:18 +02:00
|
|
|
static PyTypeObject* py3_PyStdPrinter_Type;
|
2023-10-04 20:05:05 +02:00
|
|
|
# endif
|
2010-07-17 21:19:38 +02:00
|
|
|
static PyTypeObject* py3_PySlice_Type;
|
2012-06-29 12:54:53 +02:00
|
|
|
static PyTypeObject* py3_PyFloat_Type;
|
2023-10-06 19:27:13 +02:00
|
|
|
static PyTypeObject* py3_PyBool_Type;
|
2013-06-23 14:16:57 +02:00
|
|
|
static int (*py3_PyNumber_Check)(PyObject *);
|
|
|
|
static PyObject* (*py3_PyNumber_Long)(PyObject *);
|
2011-06-19 00:27:51 +02:00
|
|
|
static PyObject* (*py3_PyErr_NewException)(char *name, PyObject *base, PyObject *dict);
|
2012-06-29 12:54:53 +02:00
|
|
|
static PyObject* (*py3_PyCapsule_New)(void *, char *, PyCapsule_Destructor);
|
|
|
|
static void* (*py3_PyCapsule_GetPointer)(PyObject *, char *);
|
2010-08-09 22:06:13 +02:00
|
|
|
# ifdef Py_DEBUG
|
2013-05-29 21:33:39 +02:00
|
|
|
static void (*py3__Py_NegativeRefcount)(const char *fname, int lineno, PyObject *op);
|
|
|
|
static Py_ssize_t* py3__Py_RefTotal;
|
|
|
|
static PyObject* (*py3_PyModule_Create2TraceRefs)(struct PyModuleDef* module, int module_api_version);
|
|
|
|
# else
|
|
|
|
static PyObject* (*py3_PyModule_Create2)(struct PyModuleDef* module, int module_api_version);
|
|
|
|
# endif
|
|
|
|
# if defined(Py_DEBUG) && !defined(Py_DEBUG_NO_PYMALLOC)
|
|
|
|
static void (*py3__PyObject_DebugFree)(void*);
|
|
|
|
static void* (*py3__PyObject_DebugMalloc)(size_t);
|
2010-08-09 22:06:13 +02:00
|
|
|
# else
|
2013-05-29 21:33:39 +02:00
|
|
|
static void (*py3_PyObject_Free)(void*);
|
|
|
|
static void* (*py3_PyObject_Malloc)(size_t);
|
2010-08-09 22:06:13 +02:00
|
|
|
# endif
|
2013-05-21 20:51:59 +02:00
|
|
|
static PyObject*(*py3__PyObject_GC_New)(PyTypeObject *);
|
|
|
|
static void(*py3_PyObject_GC_Del)(void *);
|
|
|
|
static void(*py3_PyObject_GC_UnTrack)(void *);
|
2012-06-29 12:54:53 +02:00
|
|
|
static int (*py3_PyType_IsSubtype)(PyTypeObject *, PyTypeObject *);
|
patch 9.0.1776: No support for stable Python 3 ABI
Problem: No support for stable Python 3 ABI
Solution: Support Python 3 stable ABI
Commits:
1) Support Python 3 stable ABI to allow mixed version interoperatbility
Vim currently supports embedding Python for use with plugins, and the
"dynamic" linking option allows the user to specify a locally installed
version of Python by setting `pythonthreedll`. However, one caveat is
that the Python 3 libs are not binary compatible across minor versions,
and mixing versions can potentially be dangerous (e.g. let's say Vim was
linked against the Python 3.10 SDK, but the user sets `pythonthreedll`
to a 3.11 lib). Usually, nothing bad happens, but in theory this could
lead to crashes, memory corruption, and other unpredictable behaviors.
It's also difficult for the user to tell something is wrong because Vim
has no way of reporting what Python 3 version Vim was linked with.
For Vim installed via a package manager, this usually isn't an issue
because all the dependencies would already be figured out. For prebuilt
Vim binaries like MacVim (my motivation for working on this), AppImage,
and Win32 installer this could potentially be an issue as usually a
single binary is distributed. This is more tricky when a new Python
version is released, as there's a chicken-and-egg issue with deciding
what Python version to build against and hard to keep in sync when a new
Python version just drops and we have a mix of users of different Python
versions, and a user just blindly upgrading to a new Python could lead to
bad interactions with Vim.
Python 3 does have a solution for this problem: stable ABI / limited API
(see https://docs.python.org/3/c-api/stable.html). The C SDK limits the
API to a set of functions that are promised to be stable across
versions. This pull request adds an ifdef config that allows us to turn
it on when building Vim. Vim binaries built with this option should be
safe to freely link with any Python 3 libraies without having the
constraint of having to use the same minor version.
Note: Python 2 has no such concept and this doesn't change how Python 2
integration works (not that there is going to be a new version of Python
2 that would cause compatibility issues in the future anyway).
---
Technical details:
======
The stable ABI can be accessed when we compile with the Python 3 limited
API (by defining `Py_LIMITED_API`). The Python 3 code (in `if_python3.c`
and `if_py_both.h`) would now handle this and switch to limited API
mode. Without it set, Vim will still use the full API as before so this
is an opt-in change.
The main difference is that `PyType_Object` is now an opaque struct that
we can't directly create "static types" out of, and we have to create
type objects as "heap types" instead. This is because the struct is not
stable and changes from version to version (e.g. 3.8 added a
`tp_vectorcall` field to it). I had to change all the types to be
allocated on the heap instead with just a pointer to them.
Other functions are also simply missing in limited API, or they are
introduced too late (e.g. `PyUnicode_AsUTF8AndSize` in 3.10) to it that
we need some other ways to do the same thing, so I had to abstract a few
things into macros, and sometimes re-implement functions like
`PyObject_NEW`.
One caveat is that in limited API, `OutputType` (used for replacing
`sys.stdout`) no longer inherits from `PyStdPrinter_Type` which I don't
think has any real issue other than minor differences in how they
convert to a string and missing a couple functions like `mode()` and
`fileno()`.
Also fixed an existing bug where `tp_basicsize` was set incorrectly for
`BufferObject`, `TabListObject, `WinListObject`.
Technically, there could be a small performance drop, there is a little
more indirection with accessing type objects, and some APIs like
`PyUnicode_AsUTF8AndSize` are missing, but in practice I didn't see any
difference, and any well-written Python plugin should try to avoid
excessing callbacks to the `vim` module in Python anyway.
I only tested limited API mode down to Python 3.7, which seemes to
compile and work fine. I haven't tried earlier Python versions.
2) Fix PyIter_Check on older Python vers / type##Ptr unused warning
For PyIter_Check, older versions exposed them as either macros (used in
full API), or a function (for use in limited API). A previous change
exposed PyIter_Check to the dynamic build because Python just moved it
to function-only in 3.10 anyway. Because of that, just make sure we
always grab the function in dynamic builds in earlier versions since
that's what Python eventually did anyway.
3) Move Py_LIMITED_API define to configure script
Can now use --with-python-stable-abi flag to customize what stable ABI
version to target. Can also use an env var to do so as well.
4) Show +python/dyn-stable in :version, and allow has() feature query
Not sure if the "/dyn-stable" suffix would break things, or whether we
should do it another way. Or just don't show it in version and rely on
has() feature checking.
5) Documentation first draft. Still need to implement v:python3_version
6) Fix PyIter_Check build breaks when compiling against Python 3.8
7) Add CI coverage stable ABI on Linux/Windows / make configurable on Windows
This adds configurable options for Windows make files (both MinGW and
MSVC). CI will also now exercise both traditional full API and stable
ABI for Linux and Windows in the matrix for coverage.
Also added a "dynamic" option to Linux matrix as a drive-by change to
make other scripting languages like Ruby / Perl testable under both
static and dynamic builds.
8) Fix inaccuracy in Windows docs
Python's own docs are confusing but you don't actually want to use
`python3.dll` for the dynamic linkage.
9) Add generated autoconf file
10) Add v:python3_version support
This variable indicates the version of Python3 that Vim was built
against (PY_VERSION_HEX), and will be useful to check whether the Python
library you are loading in dynamically actually fits it. When built with
stable ABI, it will be the limited ABI version instead
(`Py_LIMITED_API`), which indicates the minimum version of Python 3 the
user should have, rather than the exact match. When stable ABI is used,
we won't be exposing PY_VERSION_HEX in this var because it just doesn't
seem necessary to do so (the whole point of stable ABI is the promise
that it will work across versions), and I don't want to confuse the user
with too many variables.
Also, cleaned up some documentation, and added help tags.
11) Fix Python 3.7 compat issues
Fix a couple issues when using limited API < 3.8
- Crash on exit: In Python 3.7, if a heap-allocated type is destroyed
before all instances are, it would cause a crash later. This happens
when we destroyed `OptionsType` before calling `Py_Finalize` when
using the limited API. To make it worse, later versions changed the
semantics and now each instance has a strong reference to its own type
and the recommendation has changed to have each instance de-ref its
own type and have its type in GC traversal. To avoid dealing with
these cross-version variations, we just don't free the heap type. They
are static types in non-limited-API anyway and are designed to last
through the entirety of the app, and we also don't restart the Python
runtime and therefore do not need it to have absolutely 0 leaks.
See:
- https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-c-api
- https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api
- PyIter_Check: This function is not provided in limited APIs older than
3.8. Previously I was trying to mock it out using manual
PyType_GetSlot() but it was brittle and also does not actually work
properly for static types (it will generate a Python error). Just
return false. It does mean using limited API < 3.8 is not recommended
as you lose the functionality to handle iterators, but from playing
with plugins I couldn't find it to be an issue.
- Fix loading of PyIter_Check so it will be done when limited API < 3.8.
Otherwise loading a 3.7 Python lib will fail even if limited API was
specified to use it.
12) Make sure to only load `PyUnicode_AsUTF8AndSize` in needed in limited API
We don't use this function unless limited API >= 3.10, but we were
loading it regardless. Usually it's ok in Unix-like systems where Python
just has a single lib that we load from, but in Windows where there is a
separate python3.dll this would not work as the symbol would not have
been exposed in this more limited DLL file. This makes it much clearer
under what condition is this function needed.
closes: #12032
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
2023-08-20 21:18:38 +02:00
|
|
|
# ifdef USE_LIMITED_API
|
|
|
|
static void* (*py3_PyType_GetSlot)(PyTypeObject *, int);
|
|
|
|
static PyObject* (*py3_PyType_FromSpec)(PyType_Spec *);
|
|
|
|
# endif
|
2010-07-17 21:19:38 +02:00
|
|
|
|
2019-12-04 21:24:53 +01:00
|
|
|
// Imported exception objects
|
2010-07-17 21:19:38 +02:00
|
|
|
static PyObject *p3imp_PyExc_AttributeError;
|
|
|
|
static PyObject *p3imp_PyExc_IndexError;
|
2013-04-24 13:04:26 +02:00
|
|
|
static PyObject *p3imp_PyExc_KeyError;
|
2010-07-17 21:19:38 +02:00
|
|
|
static PyObject *p3imp_PyExc_KeyboardInterrupt;
|
|
|
|
static PyObject *p3imp_PyExc_TypeError;
|
|
|
|
static PyObject *p3imp_PyExc_ValueError;
|
2013-07-01 22:03:04 +02:00
|
|
|
static PyObject *p3imp_PyExc_SystemExit;
|
2013-05-15 15:44:28 +02:00
|
|
|
static PyObject *p3imp_PyExc_RuntimeError;
|
2013-06-10 21:27:29 +02:00
|
|
|
static PyObject *p3imp_PyExc_ImportError;
|
2013-06-23 14:16:57 +02:00
|
|
|
static PyObject *p3imp_PyExc_OverflowError;
|
2010-07-17 21:19:38 +02:00
|
|
|
|
|
|
|
# define PyExc_AttributeError p3imp_PyExc_AttributeError
|
|
|
|
# define PyExc_IndexError p3imp_PyExc_IndexError
|
2013-04-24 13:04:26 +02:00
|
|
|
# define PyExc_KeyError p3imp_PyExc_KeyError
|
2010-07-17 21:19:38 +02:00
|
|
|
# define PyExc_KeyboardInterrupt p3imp_PyExc_KeyboardInterrupt
|
|
|
|
# define PyExc_TypeError p3imp_PyExc_TypeError
|
|
|
|
# define PyExc_ValueError p3imp_PyExc_ValueError
|
2013-07-01 22:03:04 +02:00
|
|
|
# define PyExc_SystemExit p3imp_PyExc_SystemExit
|
2013-05-15 15:44:28 +02:00
|
|
|
# define PyExc_RuntimeError p3imp_PyExc_RuntimeError
|
2013-06-10 21:27:29 +02:00
|
|
|
# define PyExc_ImportError p3imp_PyExc_ImportError
|
2013-06-23 14:16:57 +02:00
|
|
|
# define PyExc_OverflowError p3imp_PyExc_OverflowError
|
2010-07-17 21:19:38 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Table of name to function pointer of python.
|
|
|
|
*/
|
|
|
|
# define PYTHON_PROC FARPROC
|
|
|
|
static struct
|
|
|
|
{
|
|
|
|
char *name;
|
|
|
|
PYTHON_PROC *ptr;
|
|
|
|
} py3_funcname_table[] =
|
|
|
|
{
|
|
|
|
{"PySys_SetArgv", (PYTHON_PROC*)&py3_PySys_SetArgv},
|
2010-11-16 19:26:02 +01:00
|
|
|
{"Py_SetPythonHome", (PYTHON_PROC*)&py3_Py_SetPythonHome},
|
2010-07-17 21:19:38 +02:00
|
|
|
{"Py_Initialize", (PYTHON_PROC*)&py3_Py_Initialize},
|
2012-09-12 20:21:43 +02:00
|
|
|
{"_PyArg_ParseTuple_SizeT", (PYTHON_PROC*)&py3_PyArg_ParseTuple},
|
|
|
|
{"_Py_BuildValue_SizeT", (PYTHON_PROC*)&py3_Py_BuildValue},
|
2011-06-19 00:27:51 +02:00
|
|
|
{"PyMem_Free", (PYTHON_PROC*)&py3_PyMem_Free},
|
2012-06-29 12:54:53 +02:00
|
|
|
{"PyMem_Malloc", (PYTHON_PROC*)&py3_PyMem_Malloc},
|
2010-07-17 21:19:38 +02:00
|
|
|
{"PyList_New", (PYTHON_PROC*)&py3_PyList_New},
|
|
|
|
{"PyGILState_Ensure", (PYTHON_PROC*)&py3_PyGILState_Ensure},
|
|
|
|
{"PyGILState_Release", (PYTHON_PROC*)&py3_PyGILState_Release},
|
|
|
|
{"PySys_SetObject", (PYTHON_PROC*)&py3_PySys_SetObject},
|
2013-06-10 21:27:29 +02:00
|
|
|
{"PySys_GetObject", (PYTHON_PROC*)&py3_PySys_GetObject},
|
2010-07-17 21:19:38 +02:00
|
|
|
{"PyList_Append", (PYTHON_PROC*)&py3_PyList_Append},
|
2013-06-10 21:27:29 +02:00
|
|
|
{"PyList_Insert", (PYTHON_PROC*)&py3_PyList_Insert},
|
2010-07-17 21:19:38 +02:00
|
|
|
{"PyList_Size", (PYTHON_PROC*)&py3_PyList_Size},
|
2012-06-29 12:54:53 +02:00
|
|
|
{"PySequence_Check", (PYTHON_PROC*)&py3_PySequence_Check},
|
|
|
|
{"PySequence_Size", (PYTHON_PROC*)&py3_PySequence_Size},
|
|
|
|
{"PySequence_GetItem", (PYTHON_PROC*)&py3_PySequence_GetItem},
|
2013-05-30 13:01:18 +02:00
|
|
|
{"PySequence_Fast", (PYTHON_PROC*)&py3_PySequence_Fast},
|
2012-06-29 12:54:53 +02:00
|
|
|
{"PyTuple_Size", (PYTHON_PROC*)&py3_PyTuple_Size},
|
|
|
|
{"PyTuple_GetItem", (PYTHON_PROC*)&py3_PyTuple_GetItem},
|
2018-07-04 22:03:25 +02:00
|
|
|
# if PY_VERSION_HEX >= 0x030601f0
|
|
|
|
{"PySlice_AdjustIndices", (PYTHON_PROC*)&py3_PySlice_AdjustIndices},
|
|
|
|
{"PySlice_Unpack", (PYTHON_PROC*)&py3_PySlice_Unpack},
|
|
|
|
# endif
|
2010-07-17 21:19:38 +02:00
|
|
|
{"PySlice_GetIndicesEx", (PYTHON_PROC*)&py3_PySlice_GetIndicesEx},
|
|
|
|
{"PyErr_NoMemory", (PYTHON_PROC*)&py3_PyErr_NoMemory},
|
|
|
|
{"Py_Finalize", (PYTHON_PROC*)&py3_Py_Finalize},
|
|
|
|
{"PyErr_SetString", (PYTHON_PROC*)&py3_PyErr_SetString},
|
2013-05-15 15:35:09 +02:00
|
|
|
{"PyErr_SetObject", (PYTHON_PROC*)&py3_PyErr_SetObject},
|
2013-06-10 21:27:29 +02:00
|
|
|
{"PyErr_ExceptionMatches", (PYTHON_PROC*)&py3_PyErr_ExceptionMatches},
|
2024-09-10 20:56:13 +02:00
|
|
|
# if defined(USE_LIMITED_API) || PY_VERSION_HEX >= 0x03080000
|
2024-08-10 09:44:20 +02:00
|
|
|
{"Py_IncRef", (PYTHON_PROC*)&py3_Py_IncRef},
|
2024-09-09 19:55:24 +02:00
|
|
|
{"Py_DecRef", (PYTHON_PROC*)&py3_Py_DecRef},
|
2024-08-10 09:44:20 +02:00
|
|
|
# endif
|
2023-10-11 21:27:06 +02:00
|
|
|
# ifdef USE_LIMITED_API
|
patch 9.0.1776: No support for stable Python 3 ABI
Problem: No support for stable Python 3 ABI
Solution: Support Python 3 stable ABI
Commits:
1) Support Python 3 stable ABI to allow mixed version interoperatbility
Vim currently supports embedding Python for use with plugins, and the
"dynamic" linking option allows the user to specify a locally installed
version of Python by setting `pythonthreedll`. However, one caveat is
that the Python 3 libs are not binary compatible across minor versions,
and mixing versions can potentially be dangerous (e.g. let's say Vim was
linked against the Python 3.10 SDK, but the user sets `pythonthreedll`
to a 3.11 lib). Usually, nothing bad happens, but in theory this could
lead to crashes, memory corruption, and other unpredictable behaviors.
It's also difficult for the user to tell something is wrong because Vim
has no way of reporting what Python 3 version Vim was linked with.
For Vim installed via a package manager, this usually isn't an issue
because all the dependencies would already be figured out. For prebuilt
Vim binaries like MacVim (my motivation for working on this), AppImage,
and Win32 installer this could potentially be an issue as usually a
single binary is distributed. This is more tricky when a new Python
version is released, as there's a chicken-and-egg issue with deciding
what Python version to build against and hard to keep in sync when a new
Python version just drops and we have a mix of users of different Python
versions, and a user just blindly upgrading to a new Python could lead to
bad interactions with Vim.
Python 3 does have a solution for this problem: stable ABI / limited API
(see https://docs.python.org/3/c-api/stable.html). The C SDK limits the
API to a set of functions that are promised to be stable across
versions. This pull request adds an ifdef config that allows us to turn
it on when building Vim. Vim binaries built with this option should be
safe to freely link with any Python 3 libraies without having the
constraint of having to use the same minor version.
Note: Python 2 has no such concept and this doesn't change how Python 2
integration works (not that there is going to be a new version of Python
2 that would cause compatibility issues in the future anyway).
---
Technical details:
======
The stable ABI can be accessed when we compile with the Python 3 limited
API (by defining `Py_LIMITED_API`). The Python 3 code (in `if_python3.c`
and `if_py_both.h`) would now handle this and switch to limited API
mode. Without it set, Vim will still use the full API as before so this
is an opt-in change.
The main difference is that `PyType_Object` is now an opaque struct that
we can't directly create "static types" out of, and we have to create
type objects as "heap types" instead. This is because the struct is not
stable and changes from version to version (e.g. 3.8 added a
`tp_vectorcall` field to it). I had to change all the types to be
allocated on the heap instead with just a pointer to them.
Other functions are also simply missing in limited API, or they are
introduced too late (e.g. `PyUnicode_AsUTF8AndSize` in 3.10) to it that
we need some other ways to do the same thing, so I had to abstract a few
things into macros, and sometimes re-implement functions like
`PyObject_NEW`.
One caveat is that in limited API, `OutputType` (used for replacing
`sys.stdout`) no longer inherits from `PyStdPrinter_Type` which I don't
think has any real issue other than minor differences in how they
convert to a string and missing a couple functions like `mode()` and
`fileno()`.
Also fixed an existing bug where `tp_basicsize` was set incorrectly for
`BufferObject`, `TabListObject, `WinListObject`.
Technically, there could be a small performance drop, there is a little
more indirection with accessing type objects, and some APIs like
`PyUnicode_AsUTF8AndSize` are missing, but in practice I didn't see any
difference, and any well-written Python plugin should try to avoid
excessing callbacks to the `vim` module in Python anyway.
I only tested limited API mode down to Python 3.7, which seemes to
compile and work fine. I haven't tried earlier Python versions.
2) Fix PyIter_Check on older Python vers / type##Ptr unused warning
For PyIter_Check, older versions exposed them as either macros (used in
full API), or a function (for use in limited API). A previous change
exposed PyIter_Check to the dynamic build because Python just moved it
to function-only in 3.10 anyway. Because of that, just make sure we
always grab the function in dynamic builds in earlier versions since
that's what Python eventually did anyway.
3) Move Py_LIMITED_API define to configure script
Can now use --with-python-stable-abi flag to customize what stable ABI
version to target. Can also use an env var to do so as well.
4) Show +python/dyn-stable in :version, and allow has() feature query
Not sure if the "/dyn-stable" suffix would break things, or whether we
should do it another way. Or just don't show it in version and rely on
has() feature checking.
5) Documentation first draft. Still need to implement v:python3_version
6) Fix PyIter_Check build breaks when compiling against Python 3.8
7) Add CI coverage stable ABI on Linux/Windows / make configurable on Windows
This adds configurable options for Windows make files (both MinGW and
MSVC). CI will also now exercise both traditional full API and stable
ABI for Linux and Windows in the matrix for coverage.
Also added a "dynamic" option to Linux matrix as a drive-by change to
make other scripting languages like Ruby / Perl testable under both
static and dynamic builds.
8) Fix inaccuracy in Windows docs
Python's own docs are confusing but you don't actually want to use
`python3.dll` for the dynamic linkage.
9) Add generated autoconf file
10) Add v:python3_version support
This variable indicates the version of Python3 that Vim was built
against (PY_VERSION_HEX), and will be useful to check whether the Python
library you are loading in dynamically actually fits it. When built with
stable ABI, it will be the limited ABI version instead
(`Py_LIMITED_API`), which indicates the minimum version of Python 3 the
user should have, rather than the exact match. When stable ABI is used,
we won't be exposing PY_VERSION_HEX in this var because it just doesn't
seem necessary to do so (the whole point of stable ABI is the promise
that it will work across versions), and I don't want to confuse the user
with too many variables.
Also, cleaned up some documentation, and added help tags.
11) Fix Python 3.7 compat issues
Fix a couple issues when using limited API < 3.8
- Crash on exit: In Python 3.7, if a heap-allocated type is destroyed
before all instances are, it would cause a crash later. This happens
when we destroyed `OptionsType` before calling `Py_Finalize` when
using the limited API. To make it worse, later versions changed the
semantics and now each instance has a strong reference to its own type
and the recommendation has changed to have each instance de-ref its
own type and have its type in GC traversal. To avoid dealing with
these cross-version variations, we just don't free the heap type. They
are static types in non-limited-API anyway and are designed to last
through the entirety of the app, and we also don't restart the Python
runtime and therefore do not need it to have absolutely 0 leaks.
See:
- https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-c-api
- https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api
- PyIter_Check: This function is not provided in limited APIs older than
3.8. Previously I was trying to mock it out using manual
PyType_GetSlot() but it was brittle and also does not actually work
properly for static types (it will generate a Python error). Just
return false. It does mean using limited API < 3.8 is not recommended
as you lose the functionality to handle iterators, but from playing
with plugins I couldn't find it to be an issue.
- Fix loading of PyIter_Check so it will be done when limited API < 3.8.
Otherwise loading a 3.7 Python lib will fail even if limited API was
specified to use it.
12) Make sure to only load `PyUnicode_AsUTF8AndSize` in needed in limited API
We don't use this function unless limited API >= 3.10, but we were
loading it regardless. Usually it's ok in Unix-like systems where Python
just has a single lib that we load from, but in Windows where there is a
separate python3.dll this would not work as the symbol would not have
been exposed in this more limited DLL file. This makes it much clearer
under what condition is this function needed.
closes: #12032
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
2023-08-20 21:18:38 +02:00
|
|
|
{"Py_CompileString", (PYTHON_PROC*)&py3_Py_CompileString},
|
|
|
|
{"PyEval_EvalCode", (PYTHON_PROC*)&PyEval_EvalCode},
|
2023-10-11 21:27:06 +02:00
|
|
|
# else
|
|
|
|
{"PyRun_SimpleString", (PYTHON_PROC*)&py3_PyRun_SimpleString},
|
|
|
|
{"PyRun_String", (PYTHON_PROC*)&py3_PyRun_String},
|
patch 9.0.1776: No support for stable Python 3 ABI
Problem: No support for stable Python 3 ABI
Solution: Support Python 3 stable ABI
Commits:
1) Support Python 3 stable ABI to allow mixed version interoperatbility
Vim currently supports embedding Python for use with plugins, and the
"dynamic" linking option allows the user to specify a locally installed
version of Python by setting `pythonthreedll`. However, one caveat is
that the Python 3 libs are not binary compatible across minor versions,
and mixing versions can potentially be dangerous (e.g. let's say Vim was
linked against the Python 3.10 SDK, but the user sets `pythonthreedll`
to a 3.11 lib). Usually, nothing bad happens, but in theory this could
lead to crashes, memory corruption, and other unpredictable behaviors.
It's also difficult for the user to tell something is wrong because Vim
has no way of reporting what Python 3 version Vim was linked with.
For Vim installed via a package manager, this usually isn't an issue
because all the dependencies would already be figured out. For prebuilt
Vim binaries like MacVim (my motivation for working on this), AppImage,
and Win32 installer this could potentially be an issue as usually a
single binary is distributed. This is more tricky when a new Python
version is released, as there's a chicken-and-egg issue with deciding
what Python version to build against and hard to keep in sync when a new
Python version just drops and we have a mix of users of different Python
versions, and a user just blindly upgrading to a new Python could lead to
bad interactions with Vim.
Python 3 does have a solution for this problem: stable ABI / limited API
(see https://docs.python.org/3/c-api/stable.html). The C SDK limits the
API to a set of functions that are promised to be stable across
versions. This pull request adds an ifdef config that allows us to turn
it on when building Vim. Vim binaries built with this option should be
safe to freely link with any Python 3 libraies without having the
constraint of having to use the same minor version.
Note: Python 2 has no such concept and this doesn't change how Python 2
integration works (not that there is going to be a new version of Python
2 that would cause compatibility issues in the future anyway).
---
Technical details:
======
The stable ABI can be accessed when we compile with the Python 3 limited
API (by defining `Py_LIMITED_API`). The Python 3 code (in `if_python3.c`
and `if_py_both.h`) would now handle this and switch to limited API
mode. Without it set, Vim will still use the full API as before so this
is an opt-in change.
The main difference is that `PyType_Object` is now an opaque struct that
we can't directly create "static types" out of, and we have to create
type objects as "heap types" instead. This is because the struct is not
stable and changes from version to version (e.g. 3.8 added a
`tp_vectorcall` field to it). I had to change all the types to be
allocated on the heap instead with just a pointer to them.
Other functions are also simply missing in limited API, or they are
introduced too late (e.g. `PyUnicode_AsUTF8AndSize` in 3.10) to it that
we need some other ways to do the same thing, so I had to abstract a few
things into macros, and sometimes re-implement functions like
`PyObject_NEW`.
One caveat is that in limited API, `OutputType` (used for replacing
`sys.stdout`) no longer inherits from `PyStdPrinter_Type` which I don't
think has any real issue other than minor differences in how they
convert to a string and missing a couple functions like `mode()` and
`fileno()`.
Also fixed an existing bug where `tp_basicsize` was set incorrectly for
`BufferObject`, `TabListObject, `WinListObject`.
Technically, there could be a small performance drop, there is a little
more indirection with accessing type objects, and some APIs like
`PyUnicode_AsUTF8AndSize` are missing, but in practice I didn't see any
difference, and any well-written Python plugin should try to avoid
excessing callbacks to the `vim` module in Python anyway.
I only tested limited API mode down to Python 3.7, which seemes to
compile and work fine. I haven't tried earlier Python versions.
2) Fix PyIter_Check on older Python vers / type##Ptr unused warning
For PyIter_Check, older versions exposed them as either macros (used in
full API), or a function (for use in limited API). A previous change
exposed PyIter_Check to the dynamic build because Python just moved it
to function-only in 3.10 anyway. Because of that, just make sure we
always grab the function in dynamic builds in earlier versions since
that's what Python eventually did anyway.
3) Move Py_LIMITED_API define to configure script
Can now use --with-python-stable-abi flag to customize what stable ABI
version to target. Can also use an env var to do so as well.
4) Show +python/dyn-stable in :version, and allow has() feature query
Not sure if the "/dyn-stable" suffix would break things, or whether we
should do it another way. Or just don't show it in version and rely on
has() feature checking.
5) Documentation first draft. Still need to implement v:python3_version
6) Fix PyIter_Check build breaks when compiling against Python 3.8
7) Add CI coverage stable ABI on Linux/Windows / make configurable on Windows
This adds configurable options for Windows make files (both MinGW and
MSVC). CI will also now exercise both traditional full API and stable
ABI for Linux and Windows in the matrix for coverage.
Also added a "dynamic" option to Linux matrix as a drive-by change to
make other scripting languages like Ruby / Perl testable under both
static and dynamic builds.
8) Fix inaccuracy in Windows docs
Python's own docs are confusing but you don't actually want to use
`python3.dll` for the dynamic linkage.
9) Add generated autoconf file
10) Add v:python3_version support
This variable indicates the version of Python3 that Vim was built
against (PY_VERSION_HEX), and will be useful to check whether the Python
library you are loading in dynamically actually fits it. When built with
stable ABI, it will be the limited ABI version instead
(`Py_LIMITED_API`), which indicates the minimum version of Python 3 the
user should have, rather than the exact match. When stable ABI is used,
we won't be exposing PY_VERSION_HEX in this var because it just doesn't
seem necessary to do so (the whole point of stable ABI is the promise
that it will work across versions), and I don't want to confuse the user
with too many variables.
Also, cleaned up some documentation, and added help tags.
11) Fix Python 3.7 compat issues
Fix a couple issues when using limited API < 3.8
- Crash on exit: In Python 3.7, if a heap-allocated type is destroyed
before all instances are, it would cause a crash later. This happens
when we destroyed `OptionsType` before calling `Py_Finalize` when
using the limited API. To make it worse, later versions changed the
semantics and now each instance has a strong reference to its own type
and the recommendation has changed to have each instance de-ref its
own type and have its type in GC traversal. To avoid dealing with
these cross-version variations, we just don't free the heap type. They
are static types in non-limited-API anyway and are designed to last
through the entirety of the app, and we also don't restart the Python
runtime and therefore do not need it to have absolutely 0 leaks.
See:
- https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-c-api
- https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api
- PyIter_Check: This function is not provided in limited APIs older than
3.8. Previously I was trying to mock it out using manual
PyType_GetSlot() but it was brittle and also does not actually work
properly for static types (it will generate a Python error). Just
return false. It does mean using limited API < 3.8 is not recommended
as you lose the functionality to handle iterators, but from playing
with plugins I couldn't find it to be an issue.
- Fix loading of PyIter_Check so it will be done when limited API < 3.8.
Otherwise loading a 3.7 Python lib will fail even if limited API was
specified to use it.
12) Make sure to only load `PyUnicode_AsUTF8AndSize` in needed in limited API
We don't use this function unless limited API >= 3.10, but we were
loading it regardless. Usually it's ok in Unix-like systems where Python
just has a single lib that we load from, but in Windows where there is a
separate python3.dll this would not work as the symbol would not have
been exposed in this more limited DLL file. This makes it much clearer
under what condition is this function needed.
closes: #12032
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
2023-08-20 21:18:38 +02:00
|
|
|
# endif
|
2013-05-15 18:28:13 +02:00
|
|
|
{"PyObject_GetAttrString", (PYTHON_PROC*)&py3_PyObject_GetAttrString},
|
2013-05-30 13:01:18 +02:00
|
|
|
{"PyObject_HasAttrString", (PYTHON_PROC*)&py3_PyObject_HasAttrString},
|
2013-05-15 18:28:13 +02:00
|
|
|
{"PyObject_SetAttrString", (PYTHON_PROC*)&py3_PyObject_SetAttrString},
|
|
|
|
{"PyObject_CallFunctionObjArgs", (PYTHON_PROC*)&py3_PyObject_CallFunctionObjArgs},
|
2024-07-04 16:36:05 +02:00
|
|
|
# if PY_VERSION_HEX >= 0x030d0000
|
|
|
|
{"PyObject_CallFunction", (PYTHON_PROC*)&py3_PyObject_CallFunction},
|
|
|
|
# else
|
2013-06-12 14:41:04 +02:00
|
|
|
{"_PyObject_CallFunction_SizeT", (PYTHON_PROC*)&py3__PyObject_CallFunction_SizeT},
|
2024-07-04 16:36:05 +02:00
|
|
|
# endif
|
2013-06-02 18:20:17 +02:00
|
|
|
{"PyObject_Call", (PYTHON_PROC*)&py3_PyObject_Call},
|
2013-05-15 18:28:13 +02:00
|
|
|
{"PyEval_GetGlobals", (PYTHON_PROC*)&py3_PyEval_GetGlobals},
|
|
|
|
{"PyEval_GetLocals", (PYTHON_PROC*)&py3_PyEval_GetLocals},
|
2010-07-17 21:19:38 +02:00
|
|
|
{"PyList_GetItem", (PYTHON_PROC*)&py3_PyList_GetItem},
|
|
|
|
{"PyImport_ImportModule", (PYTHON_PROC*)&py3_PyImport_ImportModule},
|
2012-06-29 12:54:53 +02:00
|
|
|
{"PyImport_AddModule", (PYTHON_PROC*)&py3_PyImport_AddModule},
|
2010-07-17 21:19:38 +02:00
|
|
|
{"PyErr_BadArgument", (PYTHON_PROC*)&py3_PyErr_BadArgument},
|
|
|
|
{"PyErr_Occurred", (PYTHON_PROC*)&py3_PyErr_Occurred},
|
|
|
|
{"PyModule_GetDict", (PYTHON_PROC*)&py3_PyModule_GetDict},
|
|
|
|
{"PyList_SetItem", (PYTHON_PROC*)&py3_PyList_SetItem},
|
|
|
|
{"PyDict_GetItemString", (PYTHON_PROC*)&py3_PyDict_GetItemString},
|
2012-06-29 12:54:53 +02:00
|
|
|
{"PyDict_Next", (PYTHON_PROC*)&py3_PyDict_Next},
|
|
|
|
{"PyMapping_Check", (PYTHON_PROC*)&py3_PyMapping_Check},
|
2013-05-30 13:22:13 +02:00
|
|
|
{"PyMapping_Keys", (PYTHON_PROC*)&py3_PyMapping_Keys},
|
patch 9.0.1776: No support for stable Python 3 ABI
Problem: No support for stable Python 3 ABI
Solution: Support Python 3 stable ABI
Commits:
1) Support Python 3 stable ABI to allow mixed version interoperatbility
Vim currently supports embedding Python for use with plugins, and the
"dynamic" linking option allows the user to specify a locally installed
version of Python by setting `pythonthreedll`. However, one caveat is
that the Python 3 libs are not binary compatible across minor versions,
and mixing versions can potentially be dangerous (e.g. let's say Vim was
linked against the Python 3.10 SDK, but the user sets `pythonthreedll`
to a 3.11 lib). Usually, nothing bad happens, but in theory this could
lead to crashes, memory corruption, and other unpredictable behaviors.
It's also difficult for the user to tell something is wrong because Vim
has no way of reporting what Python 3 version Vim was linked with.
For Vim installed via a package manager, this usually isn't an issue
because all the dependencies would already be figured out. For prebuilt
Vim binaries like MacVim (my motivation for working on this), AppImage,
and Win32 installer this could potentially be an issue as usually a
single binary is distributed. This is more tricky when a new Python
version is released, as there's a chicken-and-egg issue with deciding
what Python version to build against and hard to keep in sync when a new
Python version just drops and we have a mix of users of different Python
versions, and a user just blindly upgrading to a new Python could lead to
bad interactions with Vim.
Python 3 does have a solution for this problem: stable ABI / limited API
(see https://docs.python.org/3/c-api/stable.html). The C SDK limits the
API to a set of functions that are promised to be stable across
versions. This pull request adds an ifdef config that allows us to turn
it on when building Vim. Vim binaries built with this option should be
safe to freely link with any Python 3 libraies without having the
constraint of having to use the same minor version.
Note: Python 2 has no such concept and this doesn't change how Python 2
integration works (not that there is going to be a new version of Python
2 that would cause compatibility issues in the future anyway).
---
Technical details:
======
The stable ABI can be accessed when we compile with the Python 3 limited
API (by defining `Py_LIMITED_API`). The Python 3 code (in `if_python3.c`
and `if_py_both.h`) would now handle this and switch to limited API
mode. Without it set, Vim will still use the full API as before so this
is an opt-in change.
The main difference is that `PyType_Object` is now an opaque struct that
we can't directly create "static types" out of, and we have to create
type objects as "heap types" instead. This is because the struct is not
stable and changes from version to version (e.g. 3.8 added a
`tp_vectorcall` field to it). I had to change all the types to be
allocated on the heap instead with just a pointer to them.
Other functions are also simply missing in limited API, or they are
introduced too late (e.g. `PyUnicode_AsUTF8AndSize` in 3.10) to it that
we need some other ways to do the same thing, so I had to abstract a few
things into macros, and sometimes re-implement functions like
`PyObject_NEW`.
One caveat is that in limited API, `OutputType` (used for replacing
`sys.stdout`) no longer inherits from `PyStdPrinter_Type` which I don't
think has any real issue other than minor differences in how they
convert to a string and missing a couple functions like `mode()` and
`fileno()`.
Also fixed an existing bug where `tp_basicsize` was set incorrectly for
`BufferObject`, `TabListObject, `WinListObject`.
Technically, there could be a small performance drop, there is a little
more indirection with accessing type objects, and some APIs like
`PyUnicode_AsUTF8AndSize` are missing, but in practice I didn't see any
difference, and any well-written Python plugin should try to avoid
excessing callbacks to the `vim` module in Python anyway.
I only tested limited API mode down to Python 3.7, which seemes to
compile and work fine. I haven't tried earlier Python versions.
2) Fix PyIter_Check on older Python vers / type##Ptr unused warning
For PyIter_Check, older versions exposed them as either macros (used in
full API), or a function (for use in limited API). A previous change
exposed PyIter_Check to the dynamic build because Python just moved it
to function-only in 3.10 anyway. Because of that, just make sure we
always grab the function in dynamic builds in earlier versions since
that's what Python eventually did anyway.
3) Move Py_LIMITED_API define to configure script
Can now use --with-python-stable-abi flag to customize what stable ABI
version to target. Can also use an env var to do so as well.
4) Show +python/dyn-stable in :version, and allow has() feature query
Not sure if the "/dyn-stable" suffix would break things, or whether we
should do it another way. Or just don't show it in version and rely on
has() feature checking.
5) Documentation first draft. Still need to implement v:python3_version
6) Fix PyIter_Check build breaks when compiling against Python 3.8
7) Add CI coverage stable ABI on Linux/Windows / make configurable on Windows
This adds configurable options for Windows make files (both MinGW and
MSVC). CI will also now exercise both traditional full API and stable
ABI for Linux and Windows in the matrix for coverage.
Also added a "dynamic" option to Linux matrix as a drive-by change to
make other scripting languages like Ruby / Perl testable under both
static and dynamic builds.
8) Fix inaccuracy in Windows docs
Python's own docs are confusing but you don't actually want to use
`python3.dll` for the dynamic linkage.
9) Add generated autoconf file
10) Add v:python3_version support
This variable indicates the version of Python3 that Vim was built
against (PY_VERSION_HEX), and will be useful to check whether the Python
library you are loading in dynamically actually fits it. When built with
stable ABI, it will be the limited ABI version instead
(`Py_LIMITED_API`), which indicates the minimum version of Python 3 the
user should have, rather than the exact match. When stable ABI is used,
we won't be exposing PY_VERSION_HEX in this var because it just doesn't
seem necessary to do so (the whole point of stable ABI is the promise
that it will work across versions), and I don't want to confuse the user
with too many variables.
Also, cleaned up some documentation, and added help tags.
11) Fix Python 3.7 compat issues
Fix a couple issues when using limited API < 3.8
- Crash on exit: In Python 3.7, if a heap-allocated type is destroyed
before all instances are, it would cause a crash later. This happens
when we destroyed `OptionsType` before calling `Py_Finalize` when
using the limited API. To make it worse, later versions changed the
semantics and now each instance has a strong reference to its own type
and the recommendation has changed to have each instance de-ref its
own type and have its type in GC traversal. To avoid dealing with
these cross-version variations, we just don't free the heap type. They
are static types in non-limited-API anyway and are designed to last
through the entirety of the app, and we also don't restart the Python
runtime and therefore do not need it to have absolutely 0 leaks.
See:
- https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-c-api
- https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api
- PyIter_Check: This function is not provided in limited APIs older than
3.8. Previously I was trying to mock it out using manual
PyType_GetSlot() but it was brittle and also does not actually work
properly for static types (it will generate a Python error). Just
return false. It does mean using limited API < 3.8 is not recommended
as you lose the functionality to handle iterators, but from playing
with plugins I couldn't find it to be an issue.
- Fix loading of PyIter_Check so it will be done when limited API < 3.8.
Otherwise loading a 3.7 Python lib will fail even if limited API was
specified to use it.
12) Make sure to only load `PyUnicode_AsUTF8AndSize` in needed in limited API
We don't use this function unless limited API >= 3.10, but we were
loading it regardless. Usually it's ok in Unix-like systems where Python
just has a single lib that we load from, but in Windows where there is a
separate python3.dll this would not work as the symbol would not have
been exposed in this more limited DLL file. This makes it much clearer
under what condition is this function needed.
closes: #12032
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
2023-08-20 21:18:38 +02:00
|
|
|
# if (defined(USE_LIMITED_API) && Py_LIMITED_API >= 0x03080000) || \
|
|
|
|
(!defined(USE_LIMITED_API) && PY_VERSION_HEX >= 0x03080000)
|
2021-06-14 15:08:30 +02:00
|
|
|
{"PyIter_Check", (PYTHON_PROC*)&py3_PyIter_Check},
|
|
|
|
# endif
|
2012-06-29 12:54:53 +02:00
|
|
|
{"PyIter_Next", (PYTHON_PROC*)&py3_PyIter_Next},
|
|
|
|
{"PyObject_GetIter", (PYTHON_PROC*)&py3_PyObject_GetIter},
|
2013-06-23 14:16:57 +02:00
|
|
|
{"PyObject_Repr", (PYTHON_PROC*)&py3_PyObject_Repr},
|
2013-05-30 13:22:13 +02:00
|
|
|
{"PyObject_GetItem", (PYTHON_PROC*)&py3_PyObject_GetItem},
|
2013-05-15 14:51:35 +02:00
|
|
|
{"PyObject_IsTrue", (PYTHON_PROC*)&py3_PyObject_IsTrue},
|
2010-07-17 21:19:38 +02:00
|
|
|
{"PyLong_FromLong", (PYTHON_PROC*)&py3_PyLong_FromLong},
|
|
|
|
{"PyDict_New", (PYTHON_PROC*)&py3_PyDict_New},
|
patch 9.0.1776: No support for stable Python 3 ABI
Problem: No support for stable Python 3 ABI
Solution: Support Python 3 stable ABI
Commits:
1) Support Python 3 stable ABI to allow mixed version interoperatbility
Vim currently supports embedding Python for use with plugins, and the
"dynamic" linking option allows the user to specify a locally installed
version of Python by setting `pythonthreedll`. However, one caveat is
that the Python 3 libs are not binary compatible across minor versions,
and mixing versions can potentially be dangerous (e.g. let's say Vim was
linked against the Python 3.10 SDK, but the user sets `pythonthreedll`
to a 3.11 lib). Usually, nothing bad happens, but in theory this could
lead to crashes, memory corruption, and other unpredictable behaviors.
It's also difficult for the user to tell something is wrong because Vim
has no way of reporting what Python 3 version Vim was linked with.
For Vim installed via a package manager, this usually isn't an issue
because all the dependencies would already be figured out. For prebuilt
Vim binaries like MacVim (my motivation for working on this), AppImage,
and Win32 installer this could potentially be an issue as usually a
single binary is distributed. This is more tricky when a new Python
version is released, as there's a chicken-and-egg issue with deciding
what Python version to build against and hard to keep in sync when a new
Python version just drops and we have a mix of users of different Python
versions, and a user just blindly upgrading to a new Python could lead to
bad interactions with Vim.
Python 3 does have a solution for this problem: stable ABI / limited API
(see https://docs.python.org/3/c-api/stable.html). The C SDK limits the
API to a set of functions that are promised to be stable across
versions. This pull request adds an ifdef config that allows us to turn
it on when building Vim. Vim binaries built with this option should be
safe to freely link with any Python 3 libraies without having the
constraint of having to use the same minor version.
Note: Python 2 has no such concept and this doesn't change how Python 2
integration works (not that there is going to be a new version of Python
2 that would cause compatibility issues in the future anyway).
---
Technical details:
======
The stable ABI can be accessed when we compile with the Python 3 limited
API (by defining `Py_LIMITED_API`). The Python 3 code (in `if_python3.c`
and `if_py_both.h`) would now handle this and switch to limited API
mode. Without it set, Vim will still use the full API as before so this
is an opt-in change.
The main difference is that `PyType_Object` is now an opaque struct that
we can't directly create "static types" out of, and we have to create
type objects as "heap types" instead. This is because the struct is not
stable and changes from version to version (e.g. 3.8 added a
`tp_vectorcall` field to it). I had to change all the types to be
allocated on the heap instead with just a pointer to them.
Other functions are also simply missing in limited API, or they are
introduced too late (e.g. `PyUnicode_AsUTF8AndSize` in 3.10) to it that
we need some other ways to do the same thing, so I had to abstract a few
things into macros, and sometimes re-implement functions like
`PyObject_NEW`.
One caveat is that in limited API, `OutputType` (used for replacing
`sys.stdout`) no longer inherits from `PyStdPrinter_Type` which I don't
think has any real issue other than minor differences in how they
convert to a string and missing a couple functions like `mode()` and
`fileno()`.
Also fixed an existing bug where `tp_basicsize` was set incorrectly for
`BufferObject`, `TabListObject, `WinListObject`.
Technically, there could be a small performance drop, there is a little
more indirection with accessing type objects, and some APIs like
`PyUnicode_AsUTF8AndSize` are missing, but in practice I didn't see any
difference, and any well-written Python plugin should try to avoid
excessing callbacks to the `vim` module in Python anyway.
I only tested limited API mode down to Python 3.7, which seemes to
compile and work fine. I haven't tried earlier Python versions.
2) Fix PyIter_Check on older Python vers / type##Ptr unused warning
For PyIter_Check, older versions exposed them as either macros (used in
full API), or a function (for use in limited API). A previous change
exposed PyIter_Check to the dynamic build because Python just moved it
to function-only in 3.10 anyway. Because of that, just make sure we
always grab the function in dynamic builds in earlier versions since
that's what Python eventually did anyway.
3) Move Py_LIMITED_API define to configure script
Can now use --with-python-stable-abi flag to customize what stable ABI
version to target. Can also use an env var to do so as well.
4) Show +python/dyn-stable in :version, and allow has() feature query
Not sure if the "/dyn-stable" suffix would break things, or whether we
should do it another way. Or just don't show it in version and rely on
has() feature checking.
5) Documentation first draft. Still need to implement v:python3_version
6) Fix PyIter_Check build breaks when compiling against Python 3.8
7) Add CI coverage stable ABI on Linux/Windows / make configurable on Windows
This adds configurable options for Windows make files (both MinGW and
MSVC). CI will also now exercise both traditional full API and stable
ABI for Linux and Windows in the matrix for coverage.
Also added a "dynamic" option to Linux matrix as a drive-by change to
make other scripting languages like Ruby / Perl testable under both
static and dynamic builds.
8) Fix inaccuracy in Windows docs
Python's own docs are confusing but you don't actually want to use
`python3.dll` for the dynamic linkage.
9) Add generated autoconf file
10) Add v:python3_version support
This variable indicates the version of Python3 that Vim was built
against (PY_VERSION_HEX), and will be useful to check whether the Python
library you are loading in dynamically actually fits it. When built with
stable ABI, it will be the limited ABI version instead
(`Py_LIMITED_API`), which indicates the minimum version of Python 3 the
user should have, rather than the exact match. When stable ABI is used,
we won't be exposing PY_VERSION_HEX in this var because it just doesn't
seem necessary to do so (the whole point of stable ABI is the promise
that it will work across versions), and I don't want to confuse the user
with too many variables.
Also, cleaned up some documentation, and added help tags.
11) Fix Python 3.7 compat issues
Fix a couple issues when using limited API < 3.8
- Crash on exit: In Python 3.7, if a heap-allocated type is destroyed
before all instances are, it would cause a crash later. This happens
when we destroyed `OptionsType` before calling `Py_Finalize` when
using the limited API. To make it worse, later versions changed the
semantics and now each instance has a strong reference to its own type
and the recommendation has changed to have each instance de-ref its
own type and have its type in GC traversal. To avoid dealing with
these cross-version variations, we just don't free the heap type. They
are static types in non-limited-API anyway and are designed to last
through the entirety of the app, and we also don't restart the Python
runtime and therefore do not need it to have absolutely 0 leaks.
See:
- https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-c-api
- https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api
- PyIter_Check: This function is not provided in limited APIs older than
3.8. Previously I was trying to mock it out using manual
PyType_GetSlot() but it was brittle and also does not actually work
properly for static types (it will generate a Python error). Just
return false. It does mean using limited API < 3.8 is not recommended
as you lose the functionality to handle iterators, but from playing
with plugins I couldn't find it to be an issue.
- Fix loading of PyIter_Check so it will be done when limited API < 3.8.
Otherwise loading a 3.7 Python lib will fail even if limited API was
specified to use it.
12) Make sure to only load `PyUnicode_AsUTF8AndSize` in needed in limited API
We don't use this function unless limited API >= 3.10, but we were
loading it regardless. Usually it's ok in Unix-like systems where Python
just has a single lib that we load from, but in Windows where there is a
separate python3.dll this would not work as the symbol would not have
been exposed in this more limited DLL file. This makes it much clearer
under what condition is this function needed.
closes: #12032
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
2023-08-20 21:18:38 +02:00
|
|
|
# if PY_VERSION_HEX >= 0x03040000
|
2020-07-16 22:15:53 +02:00
|
|
|
{"PyType_GetFlags", (PYTHON_PROC*)&py3_PyType_GetFlags},
|
|
|
|
# endif
|
2010-07-17 21:19:38 +02:00
|
|
|
{"PyType_Ready", (PYTHON_PROC*)&py3_PyType_Ready},
|
|
|
|
{"PyDict_SetItemString", (PYTHON_PROC*)&py3_PyDict_SetItemString},
|
|
|
|
{"PyLong_AsLong", (PYTHON_PROC*)&py3_PyLong_AsLong},
|
|
|
|
{"PyErr_SetNone", (PYTHON_PROC*)&py3_PyErr_SetNone},
|
|
|
|
{"PyEval_InitThreads", (PYTHON_PROC*)&py3_PyEval_InitThreads},
|
|
|
|
{"PyEval_RestoreThread", (PYTHON_PROC*)&py3_PyEval_RestoreThread},
|
|
|
|
{"PyEval_SaveThread", (PYTHON_PROC*)&py3_PyEval_SaveThread},
|
2013-06-13 20:57:50 +02:00
|
|
|
{"_PyArg_Parse_SizeT", (PYTHON_PROC*)&py3_PyArg_Parse},
|
2010-07-17 21:19:38 +02:00
|
|
|
{"Py_IsInitialized", (PYTHON_PROC*)&py3_Py_IsInitialized},
|
2024-09-09 19:46:17 +02:00
|
|
|
# if !defined(USE_LIMITED_API) && PY_VERSION_HEX < 0x030D0000
|
2012-06-29 12:54:53 +02:00
|
|
|
{"_PyObject_NextNotImplemented", (PYTHON_PROC*)&py3__PyObject_NextNotImplemented},
|
2023-10-04 20:05:05 +02:00
|
|
|
# endif
|
2010-07-17 21:19:38 +02:00
|
|
|
{"_Py_NoneStruct", (PYTHON_PROC*)&py3__Py_NoneStruct},
|
2012-09-21 14:00:35 +02:00
|
|
|
{"_Py_FalseStruct", (PYTHON_PROC*)&py3__Py_FalseStruct},
|
|
|
|
{"_Py_TrueStruct", (PYTHON_PROC*)&py3__Py_TrueStruct},
|
2010-07-17 21:19:38 +02:00
|
|
|
{"PyErr_Clear", (PYTHON_PROC*)&py3_PyErr_Clear},
|
2013-06-23 13:46:40 +02:00
|
|
|
{"PyErr_Format", (PYTHON_PROC*)&py3_PyErr_Format},
|
2013-02-20 16:09:43 +01:00
|
|
|
{"PyErr_PrintEx", (PYTHON_PROC*)&py3_PyErr_PrintEx},
|
2010-07-17 21:19:38 +02:00
|
|
|
{"PyObject_Init", (PYTHON_PROC*)&py3__PyObject_Init},
|
|
|
|
{"PyModule_AddObject", (PYTHON_PROC*)&py3_PyModule_AddObject},
|
|
|
|
{"PyImport_AppendInittab", (PYTHON_PROC*)&py3_PyImport_AppendInittab},
|
patch 9.0.1776: No support for stable Python 3 ABI
Problem: No support for stable Python 3 ABI
Solution: Support Python 3 stable ABI
Commits:
1) Support Python 3 stable ABI to allow mixed version interoperatbility
Vim currently supports embedding Python for use with plugins, and the
"dynamic" linking option allows the user to specify a locally installed
version of Python by setting `pythonthreedll`. However, one caveat is
that the Python 3 libs are not binary compatible across minor versions,
and mixing versions can potentially be dangerous (e.g. let's say Vim was
linked against the Python 3.10 SDK, but the user sets `pythonthreedll`
to a 3.11 lib). Usually, nothing bad happens, but in theory this could
lead to crashes, memory corruption, and other unpredictable behaviors.
It's also difficult for the user to tell something is wrong because Vim
has no way of reporting what Python 3 version Vim was linked with.
For Vim installed via a package manager, this usually isn't an issue
because all the dependencies would already be figured out. For prebuilt
Vim binaries like MacVim (my motivation for working on this), AppImage,
and Win32 installer this could potentially be an issue as usually a
single binary is distributed. This is more tricky when a new Python
version is released, as there's a chicken-and-egg issue with deciding
what Python version to build against and hard to keep in sync when a new
Python version just drops and we have a mix of users of different Python
versions, and a user just blindly upgrading to a new Python could lead to
bad interactions with Vim.
Python 3 does have a solution for this problem: stable ABI / limited API
(see https://docs.python.org/3/c-api/stable.html). The C SDK limits the
API to a set of functions that are promised to be stable across
versions. This pull request adds an ifdef config that allows us to turn
it on when building Vim. Vim binaries built with this option should be
safe to freely link with any Python 3 libraies without having the
constraint of having to use the same minor version.
Note: Python 2 has no such concept and this doesn't change how Python 2
integration works (not that there is going to be a new version of Python
2 that would cause compatibility issues in the future anyway).
---
Technical details:
======
The stable ABI can be accessed when we compile with the Python 3 limited
API (by defining `Py_LIMITED_API`). The Python 3 code (in `if_python3.c`
and `if_py_both.h`) would now handle this and switch to limited API
mode. Without it set, Vim will still use the full API as before so this
is an opt-in change.
The main difference is that `PyType_Object` is now an opaque struct that
we can't directly create "static types" out of, and we have to create
type objects as "heap types" instead. This is because the struct is not
stable and changes from version to version (e.g. 3.8 added a
`tp_vectorcall` field to it). I had to change all the types to be
allocated on the heap instead with just a pointer to them.
Other functions are also simply missing in limited API, or they are
introduced too late (e.g. `PyUnicode_AsUTF8AndSize` in 3.10) to it that
we need some other ways to do the same thing, so I had to abstract a few
things into macros, and sometimes re-implement functions like
`PyObject_NEW`.
One caveat is that in limited API, `OutputType` (used for replacing
`sys.stdout`) no longer inherits from `PyStdPrinter_Type` which I don't
think has any real issue other than minor differences in how they
convert to a string and missing a couple functions like `mode()` and
`fileno()`.
Also fixed an existing bug where `tp_basicsize` was set incorrectly for
`BufferObject`, `TabListObject, `WinListObject`.
Technically, there could be a small performance drop, there is a little
more indirection with accessing type objects, and some APIs like
`PyUnicode_AsUTF8AndSize` are missing, but in practice I didn't see any
difference, and any well-written Python plugin should try to avoid
excessing callbacks to the `vim` module in Python anyway.
I only tested limited API mode down to Python 3.7, which seemes to
compile and work fine. I haven't tried earlier Python versions.
2) Fix PyIter_Check on older Python vers / type##Ptr unused warning
For PyIter_Check, older versions exposed them as either macros (used in
full API), or a function (for use in limited API). A previous change
exposed PyIter_Check to the dynamic build because Python just moved it
to function-only in 3.10 anyway. Because of that, just make sure we
always grab the function in dynamic builds in earlier versions since
that's what Python eventually did anyway.
3) Move Py_LIMITED_API define to configure script
Can now use --with-python-stable-abi flag to customize what stable ABI
version to target. Can also use an env var to do so as well.
4) Show +python/dyn-stable in :version, and allow has() feature query
Not sure if the "/dyn-stable" suffix would break things, or whether we
should do it another way. Or just don't show it in version and rely on
has() feature checking.
5) Documentation first draft. Still need to implement v:python3_version
6) Fix PyIter_Check build breaks when compiling against Python 3.8
7) Add CI coverage stable ABI on Linux/Windows / make configurable on Windows
This adds configurable options for Windows make files (both MinGW and
MSVC). CI will also now exercise both traditional full API and stable
ABI for Linux and Windows in the matrix for coverage.
Also added a "dynamic" option to Linux matrix as a drive-by change to
make other scripting languages like Ruby / Perl testable under both
static and dynamic builds.
8) Fix inaccuracy in Windows docs
Python's own docs are confusing but you don't actually want to use
`python3.dll` for the dynamic linkage.
9) Add generated autoconf file
10) Add v:python3_version support
This variable indicates the version of Python3 that Vim was built
against (PY_VERSION_HEX), and will be useful to check whether the Python
library you are loading in dynamically actually fits it. When built with
stable ABI, it will be the limited ABI version instead
(`Py_LIMITED_API`), which indicates the minimum version of Python 3 the
user should have, rather than the exact match. When stable ABI is used,
we won't be exposing PY_VERSION_HEX in this var because it just doesn't
seem necessary to do so (the whole point of stable ABI is the promise
that it will work across versions), and I don't want to confuse the user
with too many variables.
Also, cleaned up some documentation, and added help tags.
11) Fix Python 3.7 compat issues
Fix a couple issues when using limited API < 3.8
- Crash on exit: In Python 3.7, if a heap-allocated type is destroyed
before all instances are, it would cause a crash later. This happens
when we destroyed `OptionsType` before calling `Py_Finalize` when
using the limited API. To make it worse, later versions changed the
semantics and now each instance has a strong reference to its own type
and the recommendation has changed to have each instance de-ref its
own type and have its type in GC traversal. To avoid dealing with
these cross-version variations, we just don't free the heap type. They
are static types in non-limited-API anyway and are designed to last
through the entirety of the app, and we also don't restart the Python
runtime and therefore do not need it to have absolutely 0 leaks.
See:
- https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-c-api
- https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api
- PyIter_Check: This function is not provided in limited APIs older than
3.8. Previously I was trying to mock it out using manual
PyType_GetSlot() but it was brittle and also does not actually work
properly for static types (it will generate a Python error). Just
return false. It does mean using limited API < 3.8 is not recommended
as you lose the functionality to handle iterators, but from playing
with plugins I couldn't find it to be an issue.
- Fix loading of PyIter_Check so it will be done when limited API < 3.8.
Otherwise loading a 3.7 Python lib will fail even if limited API was
specified to use it.
12) Make sure to only load `PyUnicode_AsUTF8AndSize` in needed in limited API
We don't use this function unless limited API >= 3.10, but we were
loading it regardless. Usually it's ok in Unix-like systems where Python
just has a single lib that we load from, but in Windows where there is a
separate python3.dll this would not work as the symbol would not have
been exposed in this more limited DLL file. This makes it much clearer
under what condition is this function needed.
closes: #12032
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
2023-08-20 21:18:38 +02:00
|
|
|
# ifdef USE_LIMITED_API
|
|
|
|
# if Py_LIMITED_API >= 0x030a0000
|
|
|
|
{"PyUnicode_AsUTF8AndSize", (PYTHON_PROC*)&py3_PyUnicode_AsUTF8AndSize},
|
|
|
|
# endif
|
2012-10-23 05:17:37 +02:00
|
|
|
# else
|
patch 9.0.1776: No support for stable Python 3 ABI
Problem: No support for stable Python 3 ABI
Solution: Support Python 3 stable ABI
Commits:
1) Support Python 3 stable ABI to allow mixed version interoperatbility
Vim currently supports embedding Python for use with plugins, and the
"dynamic" linking option allows the user to specify a locally installed
version of Python by setting `pythonthreedll`. However, one caveat is
that the Python 3 libs are not binary compatible across minor versions,
and mixing versions can potentially be dangerous (e.g. let's say Vim was
linked against the Python 3.10 SDK, but the user sets `pythonthreedll`
to a 3.11 lib). Usually, nothing bad happens, but in theory this could
lead to crashes, memory corruption, and other unpredictable behaviors.
It's also difficult for the user to tell something is wrong because Vim
has no way of reporting what Python 3 version Vim was linked with.
For Vim installed via a package manager, this usually isn't an issue
because all the dependencies would already be figured out. For prebuilt
Vim binaries like MacVim (my motivation for working on this), AppImage,
and Win32 installer this could potentially be an issue as usually a
single binary is distributed. This is more tricky when a new Python
version is released, as there's a chicken-and-egg issue with deciding
what Python version to build against and hard to keep in sync when a new
Python version just drops and we have a mix of users of different Python
versions, and a user just blindly upgrading to a new Python could lead to
bad interactions with Vim.
Python 3 does have a solution for this problem: stable ABI / limited API
(see https://docs.python.org/3/c-api/stable.html). The C SDK limits the
API to a set of functions that are promised to be stable across
versions. This pull request adds an ifdef config that allows us to turn
it on when building Vim. Vim binaries built with this option should be
safe to freely link with any Python 3 libraies without having the
constraint of having to use the same minor version.
Note: Python 2 has no such concept and this doesn't change how Python 2
integration works (not that there is going to be a new version of Python
2 that would cause compatibility issues in the future anyway).
---
Technical details:
======
The stable ABI can be accessed when we compile with the Python 3 limited
API (by defining `Py_LIMITED_API`). The Python 3 code (in `if_python3.c`
and `if_py_both.h`) would now handle this and switch to limited API
mode. Without it set, Vim will still use the full API as before so this
is an opt-in change.
The main difference is that `PyType_Object` is now an opaque struct that
we can't directly create "static types" out of, and we have to create
type objects as "heap types" instead. This is because the struct is not
stable and changes from version to version (e.g. 3.8 added a
`tp_vectorcall` field to it). I had to change all the types to be
allocated on the heap instead with just a pointer to them.
Other functions are also simply missing in limited API, or they are
introduced too late (e.g. `PyUnicode_AsUTF8AndSize` in 3.10) to it that
we need some other ways to do the same thing, so I had to abstract a few
things into macros, and sometimes re-implement functions like
`PyObject_NEW`.
One caveat is that in limited API, `OutputType` (used for replacing
`sys.stdout`) no longer inherits from `PyStdPrinter_Type` which I don't
think has any real issue other than minor differences in how they
convert to a string and missing a couple functions like `mode()` and
`fileno()`.
Also fixed an existing bug where `tp_basicsize` was set incorrectly for
`BufferObject`, `TabListObject, `WinListObject`.
Technically, there could be a small performance drop, there is a little
more indirection with accessing type objects, and some APIs like
`PyUnicode_AsUTF8AndSize` are missing, but in practice I didn't see any
difference, and any well-written Python plugin should try to avoid
excessing callbacks to the `vim` module in Python anyway.
I only tested limited API mode down to Python 3.7, which seemes to
compile and work fine. I haven't tried earlier Python versions.
2) Fix PyIter_Check on older Python vers / type##Ptr unused warning
For PyIter_Check, older versions exposed them as either macros (used in
full API), or a function (for use in limited API). A previous change
exposed PyIter_Check to the dynamic build because Python just moved it
to function-only in 3.10 anyway. Because of that, just make sure we
always grab the function in dynamic builds in earlier versions since
that's what Python eventually did anyway.
3) Move Py_LIMITED_API define to configure script
Can now use --with-python-stable-abi flag to customize what stable ABI
version to target. Can also use an env var to do so as well.
4) Show +python/dyn-stable in :version, and allow has() feature query
Not sure if the "/dyn-stable" suffix would break things, or whether we
should do it another way. Or just don't show it in version and rely on
has() feature checking.
5) Documentation first draft. Still need to implement v:python3_version
6) Fix PyIter_Check build breaks when compiling against Python 3.8
7) Add CI coverage stable ABI on Linux/Windows / make configurable on Windows
This adds configurable options for Windows make files (both MinGW and
MSVC). CI will also now exercise both traditional full API and stable
ABI for Linux and Windows in the matrix for coverage.
Also added a "dynamic" option to Linux matrix as a drive-by change to
make other scripting languages like Ruby / Perl testable under both
static and dynamic builds.
8) Fix inaccuracy in Windows docs
Python's own docs are confusing but you don't actually want to use
`python3.dll` for the dynamic linkage.
9) Add generated autoconf file
10) Add v:python3_version support
This variable indicates the version of Python3 that Vim was built
against (PY_VERSION_HEX), and will be useful to check whether the Python
library you are loading in dynamically actually fits it. When built with
stable ABI, it will be the limited ABI version instead
(`Py_LIMITED_API`), which indicates the minimum version of Python 3 the
user should have, rather than the exact match. When stable ABI is used,
we won't be exposing PY_VERSION_HEX in this var because it just doesn't
seem necessary to do so (the whole point of stable ABI is the promise
that it will work across versions), and I don't want to confuse the user
with too many variables.
Also, cleaned up some documentation, and added help tags.
11) Fix Python 3.7 compat issues
Fix a couple issues when using limited API < 3.8
- Crash on exit: In Python 3.7, if a heap-allocated type is destroyed
before all instances are, it would cause a crash later. This happens
when we destroyed `OptionsType` before calling `Py_Finalize` when
using the limited API. To make it worse, later versions changed the
semantics and now each instance has a strong reference to its own type
and the recommendation has changed to have each instance de-ref its
own type and have its type in GC traversal. To avoid dealing with
these cross-version variations, we just don't free the heap type. They
are static types in non-limited-API anyway and are designed to last
through the entirety of the app, and we also don't restart the Python
runtime and therefore do not need it to have absolutely 0 leaks.
See:
- https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-c-api
- https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api
- PyIter_Check: This function is not provided in limited APIs older than
3.8. Previously I was trying to mock it out using manual
PyType_GetSlot() but it was brittle and also does not actually work
properly for static types (it will generate a Python error). Just
return false. It does mean using limited API < 3.8 is not recommended
as you lose the functionality to handle iterators, but from playing
with plugins I couldn't find it to be an issue.
- Fix loading of PyIter_Check so it will be done when limited API < 3.8.
Otherwise loading a 3.7 Python lib will fail even if limited API was
specified to use it.
12) Make sure to only load `PyUnicode_AsUTF8AndSize` in needed in limited API
We don't use this function unless limited API >= 3.10, but we were
loading it regardless. Usually it's ok in Unix-like systems where Python
just has a single lib that we load from, but in Windows where there is a
separate python3.dll this would not work as the symbol would not have
been exposed in this more limited DLL file. This makes it much clearer
under what condition is this function needed.
closes: #12032
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
2023-08-20 21:18:38 +02:00
|
|
|
# if PY_VERSION_HEX >= 0x030300f0
|
|
|
|
{"PyUnicode_AsUTF8AndSize", (PYTHON_PROC*)&py3_PyUnicode_AsUTF8AndSize},
|
|
|
|
# else
|
2010-07-17 21:19:38 +02:00
|
|
|
{"_PyUnicode_AsString", (PYTHON_PROC*)&py3__PyUnicode_AsString},
|
patch 9.0.1776: No support for stable Python 3 ABI
Problem: No support for stable Python 3 ABI
Solution: Support Python 3 stable ABI
Commits:
1) Support Python 3 stable ABI to allow mixed version interoperatbility
Vim currently supports embedding Python for use with plugins, and the
"dynamic" linking option allows the user to specify a locally installed
version of Python by setting `pythonthreedll`. However, one caveat is
that the Python 3 libs are not binary compatible across minor versions,
and mixing versions can potentially be dangerous (e.g. let's say Vim was
linked against the Python 3.10 SDK, but the user sets `pythonthreedll`
to a 3.11 lib). Usually, nothing bad happens, but in theory this could
lead to crashes, memory corruption, and other unpredictable behaviors.
It's also difficult for the user to tell something is wrong because Vim
has no way of reporting what Python 3 version Vim was linked with.
For Vim installed via a package manager, this usually isn't an issue
because all the dependencies would already be figured out. For prebuilt
Vim binaries like MacVim (my motivation for working on this), AppImage,
and Win32 installer this could potentially be an issue as usually a
single binary is distributed. This is more tricky when a new Python
version is released, as there's a chicken-and-egg issue with deciding
what Python version to build against and hard to keep in sync when a new
Python version just drops and we have a mix of users of different Python
versions, and a user just blindly upgrading to a new Python could lead to
bad interactions with Vim.
Python 3 does have a solution for this problem: stable ABI / limited API
(see https://docs.python.org/3/c-api/stable.html). The C SDK limits the
API to a set of functions that are promised to be stable across
versions. This pull request adds an ifdef config that allows us to turn
it on when building Vim. Vim binaries built with this option should be
safe to freely link with any Python 3 libraies without having the
constraint of having to use the same minor version.
Note: Python 2 has no such concept and this doesn't change how Python 2
integration works (not that there is going to be a new version of Python
2 that would cause compatibility issues in the future anyway).
---
Technical details:
======
The stable ABI can be accessed when we compile with the Python 3 limited
API (by defining `Py_LIMITED_API`). The Python 3 code (in `if_python3.c`
and `if_py_both.h`) would now handle this and switch to limited API
mode. Without it set, Vim will still use the full API as before so this
is an opt-in change.
The main difference is that `PyType_Object` is now an opaque struct that
we can't directly create "static types" out of, and we have to create
type objects as "heap types" instead. This is because the struct is not
stable and changes from version to version (e.g. 3.8 added a
`tp_vectorcall` field to it). I had to change all the types to be
allocated on the heap instead with just a pointer to them.
Other functions are also simply missing in limited API, or they are
introduced too late (e.g. `PyUnicode_AsUTF8AndSize` in 3.10) to it that
we need some other ways to do the same thing, so I had to abstract a few
things into macros, and sometimes re-implement functions like
`PyObject_NEW`.
One caveat is that in limited API, `OutputType` (used for replacing
`sys.stdout`) no longer inherits from `PyStdPrinter_Type` which I don't
think has any real issue other than minor differences in how they
convert to a string and missing a couple functions like `mode()` and
`fileno()`.
Also fixed an existing bug where `tp_basicsize` was set incorrectly for
`BufferObject`, `TabListObject, `WinListObject`.
Technically, there could be a small performance drop, there is a little
more indirection with accessing type objects, and some APIs like
`PyUnicode_AsUTF8AndSize` are missing, but in practice I didn't see any
difference, and any well-written Python plugin should try to avoid
excessing callbacks to the `vim` module in Python anyway.
I only tested limited API mode down to Python 3.7, which seemes to
compile and work fine. I haven't tried earlier Python versions.
2) Fix PyIter_Check on older Python vers / type##Ptr unused warning
For PyIter_Check, older versions exposed them as either macros (used in
full API), or a function (for use in limited API). A previous change
exposed PyIter_Check to the dynamic build because Python just moved it
to function-only in 3.10 anyway. Because of that, just make sure we
always grab the function in dynamic builds in earlier versions since
that's what Python eventually did anyway.
3) Move Py_LIMITED_API define to configure script
Can now use --with-python-stable-abi flag to customize what stable ABI
version to target. Can also use an env var to do so as well.
4) Show +python/dyn-stable in :version, and allow has() feature query
Not sure if the "/dyn-stable" suffix would break things, or whether we
should do it another way. Or just don't show it in version and rely on
has() feature checking.
5) Documentation first draft. Still need to implement v:python3_version
6) Fix PyIter_Check build breaks when compiling against Python 3.8
7) Add CI coverage stable ABI on Linux/Windows / make configurable on Windows
This adds configurable options for Windows make files (both MinGW and
MSVC). CI will also now exercise both traditional full API and stable
ABI for Linux and Windows in the matrix for coverage.
Also added a "dynamic" option to Linux matrix as a drive-by change to
make other scripting languages like Ruby / Perl testable under both
static and dynamic builds.
8) Fix inaccuracy in Windows docs
Python's own docs are confusing but you don't actually want to use
`python3.dll` for the dynamic linkage.
9) Add generated autoconf file
10) Add v:python3_version support
This variable indicates the version of Python3 that Vim was built
against (PY_VERSION_HEX), and will be useful to check whether the Python
library you are loading in dynamically actually fits it. When built with
stable ABI, it will be the limited ABI version instead
(`Py_LIMITED_API`), which indicates the minimum version of Python 3 the
user should have, rather than the exact match. When stable ABI is used,
we won't be exposing PY_VERSION_HEX in this var because it just doesn't
seem necessary to do so (the whole point of stable ABI is the promise
that it will work across versions), and I don't want to confuse the user
with too many variables.
Also, cleaned up some documentation, and added help tags.
11) Fix Python 3.7 compat issues
Fix a couple issues when using limited API < 3.8
- Crash on exit: In Python 3.7, if a heap-allocated type is destroyed
before all instances are, it would cause a crash later. This happens
when we destroyed `OptionsType` before calling `Py_Finalize` when
using the limited API. To make it worse, later versions changed the
semantics and now each instance has a strong reference to its own type
and the recommendation has changed to have each instance de-ref its
own type and have its type in GC traversal. To avoid dealing with
these cross-version variations, we just don't free the heap type. They
are static types in non-limited-API anyway and are designed to last
through the entirety of the app, and we also don't restart the Python
runtime and therefore do not need it to have absolutely 0 leaks.
See:
- https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-c-api
- https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api
- PyIter_Check: This function is not provided in limited APIs older than
3.8. Previously I was trying to mock it out using manual
PyType_GetSlot() but it was brittle and also does not actually work
properly for static types (it will generate a Python error). Just
return false. It does mean using limited API < 3.8 is not recommended
as you lose the functionality to handle iterators, but from playing
with plugins I couldn't find it to be an issue.
- Fix loading of PyIter_Check so it will be done when limited API < 3.8.
Otherwise loading a 3.7 Python lib will fail even if limited API was
specified to use it.
12) Make sure to only load `PyUnicode_AsUTF8AndSize` in needed in limited API
We don't use this function unless limited API >= 3.10, but we were
loading it regardless. Usually it's ok in Unix-like systems where Python
just has a single lib that we load from, but in Windows where there is a
separate python3.dll this would not work as the symbol would not have
been exposed in this more limited DLL file. This makes it much clearer
under what condition is this function needed.
closes: #12032
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
2023-08-20 21:18:38 +02:00
|
|
|
# endif
|
2013-05-30 12:40:39 +02:00
|
|
|
# endif
|
patch 9.0.1776: No support for stable Python 3 ABI
Problem: No support for stable Python 3 ABI
Solution: Support Python 3 stable ABI
Commits:
1) Support Python 3 stable ABI to allow mixed version interoperatbility
Vim currently supports embedding Python for use with plugins, and the
"dynamic" linking option allows the user to specify a locally installed
version of Python by setting `pythonthreedll`. However, one caveat is
that the Python 3 libs are not binary compatible across minor versions,
and mixing versions can potentially be dangerous (e.g. let's say Vim was
linked against the Python 3.10 SDK, but the user sets `pythonthreedll`
to a 3.11 lib). Usually, nothing bad happens, but in theory this could
lead to crashes, memory corruption, and other unpredictable behaviors.
It's also difficult for the user to tell something is wrong because Vim
has no way of reporting what Python 3 version Vim was linked with.
For Vim installed via a package manager, this usually isn't an issue
because all the dependencies would already be figured out. For prebuilt
Vim binaries like MacVim (my motivation for working on this), AppImage,
and Win32 installer this could potentially be an issue as usually a
single binary is distributed. This is more tricky when a new Python
version is released, as there's a chicken-and-egg issue with deciding
what Python version to build against and hard to keep in sync when a new
Python version just drops and we have a mix of users of different Python
versions, and a user just blindly upgrading to a new Python could lead to
bad interactions with Vim.
Python 3 does have a solution for this problem: stable ABI / limited API
(see https://docs.python.org/3/c-api/stable.html). The C SDK limits the
API to a set of functions that are promised to be stable across
versions. This pull request adds an ifdef config that allows us to turn
it on when building Vim. Vim binaries built with this option should be
safe to freely link with any Python 3 libraies without having the
constraint of having to use the same minor version.
Note: Python 2 has no such concept and this doesn't change how Python 2
integration works (not that there is going to be a new version of Python
2 that would cause compatibility issues in the future anyway).
---
Technical details:
======
The stable ABI can be accessed when we compile with the Python 3 limited
API (by defining `Py_LIMITED_API`). The Python 3 code (in `if_python3.c`
and `if_py_both.h`) would now handle this and switch to limited API
mode. Without it set, Vim will still use the full API as before so this
is an opt-in change.
The main difference is that `PyType_Object` is now an opaque struct that
we can't directly create "static types" out of, and we have to create
type objects as "heap types" instead. This is because the struct is not
stable and changes from version to version (e.g. 3.8 added a
`tp_vectorcall` field to it). I had to change all the types to be
allocated on the heap instead with just a pointer to them.
Other functions are also simply missing in limited API, or they are
introduced too late (e.g. `PyUnicode_AsUTF8AndSize` in 3.10) to it that
we need some other ways to do the same thing, so I had to abstract a few
things into macros, and sometimes re-implement functions like
`PyObject_NEW`.
One caveat is that in limited API, `OutputType` (used for replacing
`sys.stdout`) no longer inherits from `PyStdPrinter_Type` which I don't
think has any real issue other than minor differences in how they
convert to a string and missing a couple functions like `mode()` and
`fileno()`.
Also fixed an existing bug where `tp_basicsize` was set incorrectly for
`BufferObject`, `TabListObject, `WinListObject`.
Technically, there could be a small performance drop, there is a little
more indirection with accessing type objects, and some APIs like
`PyUnicode_AsUTF8AndSize` are missing, but in practice I didn't see any
difference, and any well-written Python plugin should try to avoid
excessing callbacks to the `vim` module in Python anyway.
I only tested limited API mode down to Python 3.7, which seemes to
compile and work fine. I haven't tried earlier Python versions.
2) Fix PyIter_Check on older Python vers / type##Ptr unused warning
For PyIter_Check, older versions exposed them as either macros (used in
full API), or a function (for use in limited API). A previous change
exposed PyIter_Check to the dynamic build because Python just moved it
to function-only in 3.10 anyway. Because of that, just make sure we
always grab the function in dynamic builds in earlier versions since
that's what Python eventually did anyway.
3) Move Py_LIMITED_API define to configure script
Can now use --with-python-stable-abi flag to customize what stable ABI
version to target. Can also use an env var to do so as well.
4) Show +python/dyn-stable in :version, and allow has() feature query
Not sure if the "/dyn-stable" suffix would break things, or whether we
should do it another way. Or just don't show it in version and rely on
has() feature checking.
5) Documentation first draft. Still need to implement v:python3_version
6) Fix PyIter_Check build breaks when compiling against Python 3.8
7) Add CI coverage stable ABI on Linux/Windows / make configurable on Windows
This adds configurable options for Windows make files (both MinGW and
MSVC). CI will also now exercise both traditional full API and stable
ABI for Linux and Windows in the matrix for coverage.
Also added a "dynamic" option to Linux matrix as a drive-by change to
make other scripting languages like Ruby / Perl testable under both
static and dynamic builds.
8) Fix inaccuracy in Windows docs
Python's own docs are confusing but you don't actually want to use
`python3.dll` for the dynamic linkage.
9) Add generated autoconf file
10) Add v:python3_version support
This variable indicates the version of Python3 that Vim was built
against (PY_VERSION_HEX), and will be useful to check whether the Python
library you are loading in dynamically actually fits it. When built with
stable ABI, it will be the limited ABI version instead
(`Py_LIMITED_API`), which indicates the minimum version of Python 3 the
user should have, rather than the exact match. When stable ABI is used,
we won't be exposing PY_VERSION_HEX in this var because it just doesn't
seem necessary to do so (the whole point of stable ABI is the promise
that it will work across versions), and I don't want to confuse the user
with too many variables.
Also, cleaned up some documentation, and added help tags.
11) Fix Python 3.7 compat issues
Fix a couple issues when using limited API < 3.8
- Crash on exit: In Python 3.7, if a heap-allocated type is destroyed
before all instances are, it would cause a crash later. This happens
when we destroyed `OptionsType` before calling `Py_Finalize` when
using the limited API. To make it worse, later versions changed the
semantics and now each instance has a strong reference to its own type
and the recommendation has changed to have each instance de-ref its
own type and have its type in GC traversal. To avoid dealing with
these cross-version variations, we just don't free the heap type. They
are static types in non-limited-API anyway and are designed to last
through the entirety of the app, and we also don't restart the Python
runtime and therefore do not need it to have absolutely 0 leaks.
See:
- https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-c-api
- https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api
- PyIter_Check: This function is not provided in limited APIs older than
3.8. Previously I was trying to mock it out using manual
PyType_GetSlot() but it was brittle and also does not actually work
properly for static types (it will generate a Python error). Just
return false. It does mean using limited API < 3.8 is not recommended
as you lose the functionality to handle iterators, but from playing
with plugins I couldn't find it to be an issue.
- Fix loading of PyIter_Check so it will be done when limited API < 3.8.
Otherwise loading a 3.7 Python lib will fail even if limited API was
specified to use it.
12) Make sure to only load `PyUnicode_AsUTF8AndSize` in needed in limited API
We don't use this function unless limited API >= 3.10, but we were
loading it regardless. Usually it's ok in Unix-like systems where Python
just has a single lib that we load from, but in Windows where there is a
separate python3.dll this would not work as the symbol would not have
been exposed in this more limited DLL file. This makes it much clearer
under what condition is this function needed.
closes: #12032
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
2023-08-20 21:18:38 +02:00
|
|
|
{"PyUnicode_CompareWithASCIIString", (PYTHON_PROC*)&py3_PyUnicode_CompareWithASCIIString},
|
|
|
|
{"PyUnicode_AsUTF8String", (PYTHON_PROC*)&py3_PyUnicode_AsUTF8String},
|
2023-10-11 21:27:06 +02:00
|
|
|
# ifdef Py_UNICODE_USE_UCS_FUNCTIONS
|
2013-05-30 12:40:39 +02:00
|
|
|
# ifdef Py_UNICODE_WIDE
|
|
|
|
{"PyUnicodeUCS4_FromFormat", (PYTHON_PROC*)&py3_PyUnicodeUCS4_FromFormat},
|
|
|
|
# else
|
|
|
|
{"PyUnicodeUCS2_FromFormat", (PYTHON_PROC*)&py3_PyUnicodeUCS2_FromFormat},
|
|
|
|
# endif
|
2023-10-11 21:27:06 +02:00
|
|
|
# else
|
|
|
|
{"PyUnicode_FromFormat", (PYTHON_PROC*)&py3_PyUnicode_FromFormat},
|
2012-10-23 05:17:37 +02:00
|
|
|
# endif
|
2011-06-19 00:27:51 +02:00
|
|
|
{"PyBytes_AsString", (PYTHON_PROC*)&py3_PyBytes_AsString},
|
2012-09-05 19:03:56 +02:00
|
|
|
{"PyBytes_AsStringAndSize", (PYTHON_PROC*)&py3_PyBytes_AsStringAndSize},
|
2012-06-29 12:54:53 +02:00
|
|
|
{"PyBytes_FromString", (PYTHON_PROC*)&py3_PyBytes_FromString},
|
2019-01-12 22:47:31 +01:00
|
|
|
{"PyBytes_FromStringAndSize", (PYTHON_PROC*)&py3_PyBytes_FromStringAndSize},
|
2020-07-16 22:15:53 +02:00
|
|
|
# if PY_VERSION_HEX >= 0x030900b0
|
|
|
|
{"_PyObject_New", (PYTHON_PROC*)&py3__PyObject_New},
|
|
|
|
# endif
|
2012-06-29 12:54:53 +02:00
|
|
|
{"PyFloat_FromDouble", (PYTHON_PROC*)&py3_PyFloat_FromDouble},
|
|
|
|
{"PyFloat_AsDouble", (PYTHON_PROC*)&py3_PyFloat_AsDouble},
|
2010-07-17 21:19:38 +02:00
|
|
|
{"PyObject_GenericGetAttr", (PYTHON_PROC*)&py3_PyObject_GenericGetAttr},
|
|
|
|
{"PyType_GenericAlloc", (PYTHON_PROC*)&py3_PyType_GenericAlloc},
|
|
|
|
{"PyType_GenericNew", (PYTHON_PROC*)&py3_PyType_GenericNew},
|
2012-09-21 14:00:35 +02:00
|
|
|
{"PyType_Type", (PYTHON_PROC*)&py3_PyType_Type},
|
2023-10-04 20:05:05 +02:00
|
|
|
# ifndef USE_LIMITED_API
|
2018-05-15 22:31:18 +02:00
|
|
|
{"PyStdPrinter_Type", (PYTHON_PROC*)&py3_PyStdPrinter_Type},
|
2023-10-04 20:05:05 +02:00
|
|
|
# endif
|
2010-07-17 21:19:38 +02:00
|
|
|
{"PySlice_Type", (PYTHON_PROC*)&py3_PySlice_Type},
|
2012-06-29 12:54:53 +02:00
|
|
|
{"PyFloat_Type", (PYTHON_PROC*)&py3_PyFloat_Type},
|
2012-09-21 14:00:35 +02:00
|
|
|
{"PyBool_Type", (PYTHON_PROC*)&py3_PyBool_Type},
|
2013-06-23 14:16:57 +02:00
|
|
|
{"PyNumber_Check", (PYTHON_PROC*)&py3_PyNumber_Check},
|
|
|
|
{"PyNumber_Long", (PYTHON_PROC*)&py3_PyNumber_Long},
|
2011-06-19 00:27:51 +02:00
|
|
|
{"PyErr_NewException", (PYTHON_PROC*)&py3_PyErr_NewException},
|
2010-08-09 22:06:13 +02:00
|
|
|
# ifdef Py_DEBUG
|
2010-07-17 21:19:38 +02:00
|
|
|
{"_Py_NegativeRefcount", (PYTHON_PROC*)&py3__Py_NegativeRefcount},
|
|
|
|
{"_Py_RefTotal", (PYTHON_PROC*)&py3__Py_RefTotal},
|
2013-05-29 21:33:39 +02:00
|
|
|
{"PyModule_Create2TraceRefs", (PYTHON_PROC*)&py3_PyModule_Create2TraceRefs},
|
|
|
|
# else
|
|
|
|
{"PyModule_Create2", (PYTHON_PROC*)&py3_PyModule_Create2},
|
|
|
|
# endif
|
|
|
|
# if defined(Py_DEBUG) && !defined(Py_DEBUG_NO_PYMALLOC)
|
2010-07-17 21:19:38 +02:00
|
|
|
{"_PyObject_DebugFree", (PYTHON_PROC*)&py3__PyObject_DebugFree},
|
|
|
|
{"_PyObject_DebugMalloc", (PYTHON_PROC*)&py3__PyObject_DebugMalloc},
|
2010-08-09 22:06:13 +02:00
|
|
|
# else
|
2010-07-17 21:19:38 +02:00
|
|
|
{"PyObject_Malloc", (PYTHON_PROC*)&py3_PyObject_Malloc},
|
|
|
|
{"PyObject_Free", (PYTHON_PROC*)&py3_PyObject_Free},
|
2010-08-09 22:06:13 +02:00
|
|
|
# endif
|
2013-05-21 20:51:59 +02:00
|
|
|
{"_PyObject_GC_New", (PYTHON_PROC*)&py3__PyObject_GC_New},
|
|
|
|
{"PyObject_GC_Del", (PYTHON_PROC*)&py3_PyObject_GC_Del},
|
|
|
|
{"PyObject_GC_UnTrack", (PYTHON_PROC*)&py3_PyObject_GC_UnTrack},
|
2012-06-29 12:54:53 +02:00
|
|
|
{"PyType_IsSubtype", (PYTHON_PROC*)&py3_PyType_IsSubtype},
|
|
|
|
{"PyCapsule_New", (PYTHON_PROC*)&py3_PyCapsule_New},
|
|
|
|
{"PyCapsule_GetPointer", (PYTHON_PROC*)&py3_PyCapsule_GetPointer},
|
patch 9.0.1776: No support for stable Python 3 ABI
Problem: No support for stable Python 3 ABI
Solution: Support Python 3 stable ABI
Commits:
1) Support Python 3 stable ABI to allow mixed version interoperatbility
Vim currently supports embedding Python for use with plugins, and the
"dynamic" linking option allows the user to specify a locally installed
version of Python by setting `pythonthreedll`. However, one caveat is
that the Python 3 libs are not binary compatible across minor versions,
and mixing versions can potentially be dangerous (e.g. let's say Vim was
linked against the Python 3.10 SDK, but the user sets `pythonthreedll`
to a 3.11 lib). Usually, nothing bad happens, but in theory this could
lead to crashes, memory corruption, and other unpredictable behaviors.
It's also difficult for the user to tell something is wrong because Vim
has no way of reporting what Python 3 version Vim was linked with.
For Vim installed via a package manager, this usually isn't an issue
because all the dependencies would already be figured out. For prebuilt
Vim binaries like MacVim (my motivation for working on this), AppImage,
and Win32 installer this could potentially be an issue as usually a
single binary is distributed. This is more tricky when a new Python
version is released, as there's a chicken-and-egg issue with deciding
what Python version to build against and hard to keep in sync when a new
Python version just drops and we have a mix of users of different Python
versions, and a user just blindly upgrading to a new Python could lead to
bad interactions with Vim.
Python 3 does have a solution for this problem: stable ABI / limited API
(see https://docs.python.org/3/c-api/stable.html). The C SDK limits the
API to a set of functions that are promised to be stable across
versions. This pull request adds an ifdef config that allows us to turn
it on when building Vim. Vim binaries built with this option should be
safe to freely link with any Python 3 libraies without having the
constraint of having to use the same minor version.
Note: Python 2 has no such concept and this doesn't change how Python 2
integration works (not that there is going to be a new version of Python
2 that would cause compatibility issues in the future anyway).
---
Technical details:
======
The stable ABI can be accessed when we compile with the Python 3 limited
API (by defining `Py_LIMITED_API`). The Python 3 code (in `if_python3.c`
and `if_py_both.h`) would now handle this and switch to limited API
mode. Without it set, Vim will still use the full API as before so this
is an opt-in change.
The main difference is that `PyType_Object` is now an opaque struct that
we can't directly create "static types" out of, and we have to create
type objects as "heap types" instead. This is because the struct is not
stable and changes from version to version (e.g. 3.8 added a
`tp_vectorcall` field to it). I had to change all the types to be
allocated on the heap instead with just a pointer to them.
Other functions are also simply missing in limited API, or they are
introduced too late (e.g. `PyUnicode_AsUTF8AndSize` in 3.10) to it that
we need some other ways to do the same thing, so I had to abstract a few
things into macros, and sometimes re-implement functions like
`PyObject_NEW`.
One caveat is that in limited API, `OutputType` (used for replacing
`sys.stdout`) no longer inherits from `PyStdPrinter_Type` which I don't
think has any real issue other than minor differences in how they
convert to a string and missing a couple functions like `mode()` and
`fileno()`.
Also fixed an existing bug where `tp_basicsize` was set incorrectly for
`BufferObject`, `TabListObject, `WinListObject`.
Technically, there could be a small performance drop, there is a little
more indirection with accessing type objects, and some APIs like
`PyUnicode_AsUTF8AndSize` are missing, but in practice I didn't see any
difference, and any well-written Python plugin should try to avoid
excessing callbacks to the `vim` module in Python anyway.
I only tested limited API mode down to Python 3.7, which seemes to
compile and work fine. I haven't tried earlier Python versions.
2) Fix PyIter_Check on older Python vers / type##Ptr unused warning
For PyIter_Check, older versions exposed them as either macros (used in
full API), or a function (for use in limited API). A previous change
exposed PyIter_Check to the dynamic build because Python just moved it
to function-only in 3.10 anyway. Because of that, just make sure we
always grab the function in dynamic builds in earlier versions since
that's what Python eventually did anyway.
3) Move Py_LIMITED_API define to configure script
Can now use --with-python-stable-abi flag to customize what stable ABI
version to target. Can also use an env var to do so as well.
4) Show +python/dyn-stable in :version, and allow has() feature query
Not sure if the "/dyn-stable" suffix would break things, or whether we
should do it another way. Or just don't show it in version and rely on
has() feature checking.
5) Documentation first draft. Still need to implement v:python3_version
6) Fix PyIter_Check build breaks when compiling against Python 3.8
7) Add CI coverage stable ABI on Linux/Windows / make configurable on Windows
This adds configurable options for Windows make files (both MinGW and
MSVC). CI will also now exercise both traditional full API and stable
ABI for Linux and Windows in the matrix for coverage.
Also added a "dynamic" option to Linux matrix as a drive-by change to
make other scripting languages like Ruby / Perl testable under both
static and dynamic builds.
8) Fix inaccuracy in Windows docs
Python's own docs are confusing but you don't actually want to use
`python3.dll` for the dynamic linkage.
9) Add generated autoconf file
10) Add v:python3_version support
This variable indicates the version of Python3 that Vim was built
against (PY_VERSION_HEX), and will be useful to check whether the Python
library you are loading in dynamically actually fits it. When built with
stable ABI, it will be the limited ABI version instead
(`Py_LIMITED_API`), which indicates the minimum version of Python 3 the
user should have, rather than the exact match. When stable ABI is used,
we won't be exposing PY_VERSION_HEX in this var because it just doesn't
seem necessary to do so (the whole point of stable ABI is the promise
that it will work across versions), and I don't want to confuse the user
with too many variables.
Also, cleaned up some documentation, and added help tags.
11) Fix Python 3.7 compat issues
Fix a couple issues when using limited API < 3.8
- Crash on exit: In Python 3.7, if a heap-allocated type is destroyed
before all instances are, it would cause a crash later. This happens
when we destroyed `OptionsType` before calling `Py_Finalize` when
using the limited API. To make it worse, later versions changed the
semantics and now each instance has a strong reference to its own type
and the recommendation has changed to have each instance de-ref its
own type and have its type in GC traversal. To avoid dealing with
these cross-version variations, we just don't free the heap type. They
are static types in non-limited-API anyway and are designed to last
through the entirety of the app, and we also don't restart the Python
runtime and therefore do not need it to have absolutely 0 leaks.
See:
- https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-c-api
- https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api
- PyIter_Check: This function is not provided in limited APIs older than
3.8. Previously I was trying to mock it out using manual
PyType_GetSlot() but it was brittle and also does not actually work
properly for static types (it will generate a Python error). Just
return false. It does mean using limited API < 3.8 is not recommended
as you lose the functionality to handle iterators, but from playing
with plugins I couldn't find it to be an issue.
- Fix loading of PyIter_Check so it will be done when limited API < 3.8.
Otherwise loading a 3.7 Python lib will fail even if limited API was
specified to use it.
12) Make sure to only load `PyUnicode_AsUTF8AndSize` in needed in limited API
We don't use this function unless limited API >= 3.10, but we were
loading it regardless. Usually it's ok in Unix-like systems where Python
just has a single lib that we load from, but in Windows where there is a
separate python3.dll this would not work as the symbol would not have
been exposed in this more limited DLL file. This makes it much clearer
under what condition is this function needed.
closes: #12032
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
2023-08-20 21:18:38 +02:00
|
|
|
# ifdef USE_LIMITED_API
|
|
|
|
# if PY_VERSION_HEX >= 0x03040000
|
|
|
|
{"PyType_GetSlot", (PYTHON_PROC*)&py3_PyType_GetSlot},
|
|
|
|
# endif
|
|
|
|
{"PyType_FromSpec", (PYTHON_PROC*)&py3_PyType_FromSpec},
|
|
|
|
# endif
|
2010-07-17 21:19:38 +02:00
|
|
|
{"", NULL},
|
|
|
|
};
|
|
|
|
|
2024-09-10 20:56:13 +02:00
|
|
|
# if defined(USE_LIMITED_API) || PY_VERSION_HEX >= 0x03080000
|
2024-09-09 19:55:24 +02:00
|
|
|
// Use stable versions of inc/dec ref. Note that these always null-check and
|
|
|
|
// therefore there's no difference between XINCREF and INCREF.
|
2024-09-10 20:56:13 +02:00
|
|
|
//
|
|
|
|
// For 3.8 or above, we also use this version even if not using limited API.
|
|
|
|
// The Py_DECREF macros in 3.8+ include references to internal functions which
|
|
|
|
// cause link errors when building Vim. The stable versions are exposed as API
|
|
|
|
// functions and don't have these problems (albeit slightly slower as they
|
|
|
|
// require function calls rather than an inlined macro).
|
2024-09-09 19:55:24 +02:00
|
|
|
# undef Py_INCREF
|
|
|
|
# define Py_INCREF(obj) Py_IncRef((PyObject *)obj)
|
2024-08-10 09:44:20 +02:00
|
|
|
# undef Py_XINCREF
|
2024-09-09 19:55:24 +02:00
|
|
|
# define Py_XINCREF(obj) Py_IncRef((PyObject *)obj)
|
|
|
|
|
|
|
|
# undef Py_DECREF
|
|
|
|
# define Py_DECREF(obj) Py_DecRef((PyObject *)obj)
|
|
|
|
# undef Py_XDECREF
|
|
|
|
# define Py_XDECREF(obj) Py_DecRef((PyObject *)obj)
|
2024-08-10 09:44:20 +02:00
|
|
|
# endif
|
|
|
|
|
2020-07-16 22:15:53 +02:00
|
|
|
# if PY_VERSION_HEX >= 0x030900b0
|
|
|
|
static inline int
|
|
|
|
py3_PyType_HasFeature(PyTypeObject *type, unsigned long feature)
|
|
|
|
{
|
|
|
|
return ((PyType_GetFlags(type) & feature) != 0);
|
|
|
|
}
|
|
|
|
# define PyType_HasFeature(t,f) py3_PyType_HasFeature(t,f)
|
|
|
|
# endif
|
|
|
|
|
2021-06-14 15:08:30 +02:00
|
|
|
# if PY_VERSION_HEX >= 0x030a00b2
|
|
|
|
static inline int
|
|
|
|
py3__PyObject_TypeCheck(PyObject *ob, PyTypeObject *type)
|
|
|
|
{
|
|
|
|
return Py_IS_TYPE(ob, type) || PyType_IsSubtype(Py_TYPE(ob), type);
|
|
|
|
}
|
2022-06-27 13:59:00 +01:00
|
|
|
# if PY_VERSION_HEX >= 0x030b00b3
|
|
|
|
# undef PyObject_TypeCheck
|
|
|
|
# define PyObject_TypeCheck(o,t) py3__PyObject_TypeCheck(o,t)
|
|
|
|
# else
|
|
|
|
# define _PyObject_TypeCheck(o,t) py3__PyObject_TypeCheck(o,t)
|
|
|
|
# endif
|
2021-06-14 15:08:30 +02:00
|
|
|
# endif
|
|
|
|
|
2023-10-06 19:27:13 +02:00
|
|
|
# if !defined(USE_LIMITED_API) && PY_VERSION_HEX >= 0x030c00b0
|
2023-10-17 10:38:11 +02:00
|
|
|
// PyTuple_GET_SIZE/PyList_GET_SIZE are inlined functions that use Py_SIZE(),
|
|
|
|
// which started to introduce linkage dependency from Python 3.12. When we
|
|
|
|
// build Python in dynamic mode, we don't link against it in build time, and
|
|
|
|
// this would fail to build. Just use the non-inlined version instead.
|
2023-10-06 19:27:13 +02:00
|
|
|
# undef PyTuple_GET_SIZE
|
2023-10-17 10:38:11 +02:00
|
|
|
# define PyTuple_GET_SIZE(o) PyTuple_Size(o)
|
2023-10-06 19:27:13 +02:00
|
|
|
# undef PyList_GET_SIZE
|
2023-10-17 10:38:11 +02:00
|
|
|
# define PyList_GET_SIZE(o) PyList_Size(o)
|
2023-10-06 19:27:13 +02:00
|
|
|
# endif
|
|
|
|
|
2020-12-25 13:52:37 +01:00
|
|
|
# ifdef MSWIN
|
|
|
|
/*
|
|
|
|
* Look up the library "libname" using the InstallPath registry key.
|
|
|
|
* Return NULL when failed. Return an allocated string when successful.
|
|
|
|
*/
|
2023-10-14 11:49:09 +02:00
|
|
|
static WCHAR *
|
2020-12-25 13:52:37 +01:00
|
|
|
py3_get_system_libname(const char *libname)
|
|
|
|
{
|
2023-10-14 11:49:09 +02:00
|
|
|
const WCHAR *pythoncore = L"Software\\Python\\PythonCore";
|
2020-12-25 13:52:37 +01:00
|
|
|
const char *cp = libname;
|
2023-10-14 11:49:09 +02:00
|
|
|
WCHAR subkey[128];
|
2020-12-25 13:52:37 +01:00
|
|
|
HKEY hKey;
|
2023-10-14 11:49:09 +02:00
|
|
|
int i;
|
|
|
|
DWORD j, len;
|
|
|
|
LSTATUS ret;
|
2020-12-25 13:52:37 +01:00
|
|
|
|
|
|
|
while (*cp != '\0')
|
|
|
|
{
|
|
|
|
if (*cp == ':' || *cp == '\\' || *cp == '/')
|
|
|
|
{
|
|
|
|
// Bail out if "libname" contains path separator, assume it is
|
|
|
|
// an absolute path.
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
++cp;
|
|
|
|
}
|
2023-10-14 11:49:09 +02:00
|
|
|
|
|
|
|
WCHAR keyfound[32];
|
|
|
|
HKEY hKeyTop[] = {HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE};
|
|
|
|
HKEY hKeyFound = NULL;
|
|
|
|
# ifdef USE_LIMITED_API
|
|
|
|
long maxminor = -1;
|
|
|
|
# endif
|
|
|
|
for (i = 0; i < ARRAY_LENGTH(hKeyTop); i++)
|
|
|
|
{
|
|
|
|
long major, minor;
|
|
|
|
|
|
|
|
ret = RegOpenKeyExW(hKeyTop[i], pythoncore, 0, KEY_READ, &hKey);
|
|
|
|
if (ret != ERROR_SUCCESS)
|
|
|
|
continue;
|
|
|
|
for (j = 0;; j++)
|
|
|
|
{
|
|
|
|
WCHAR keyname[32];
|
|
|
|
WCHAR *wp;
|
|
|
|
|
|
|
|
len = ARRAY_LENGTH(keyname);
|
|
|
|
ret = RegEnumKeyExW(hKey, j, keyname, &len,
|
|
|
|
NULL, NULL, NULL, NULL);
|
|
|
|
if (ret == ERROR_NO_MORE_ITEMS)
|
|
|
|
break;
|
|
|
|
|
|
|
|
major = wcstol(keyname, &wp, 10);
|
2023-10-18 12:02:24 +02:00
|
|
|
if (*wp != L'.')
|
|
|
|
continue;
|
|
|
|
minor = wcstol(wp + 1, &wp, 10);
|
2020-12-25 13:52:37 +01:00
|
|
|
# ifdef _WIN64
|
2023-10-14 11:49:09 +02:00
|
|
|
if (*wp != L'\0')
|
|
|
|
continue;
|
2020-12-25 13:52:37 +01:00
|
|
|
# else
|
2023-10-14 11:49:09 +02:00
|
|
|
if (wcscmp(wp, L"-32") != 0)
|
|
|
|
continue;
|
2020-12-25 13:52:37 +01:00
|
|
|
# endif
|
2023-10-14 11:49:09 +02:00
|
|
|
|
|
|
|
if (major != PY_MAJOR_VERSION)
|
|
|
|
continue;
|
|
|
|
# ifdef USE_LIMITED_API
|
|
|
|
// Search the latest version.
|
|
|
|
if ((minor > maxminor)
|
|
|
|
&& (minor >= ((Py_LIMITED_API >> 16) & 0xff)))
|
|
|
|
{
|
|
|
|
maxminor = minor;
|
|
|
|
wcscpy(keyfound, keyname);
|
|
|
|
hKeyFound = hKeyTop[i];
|
|
|
|
}
|
|
|
|
# else
|
|
|
|
// Check if it matches with the compiled version.
|
|
|
|
if (minor == PY_MINOR_VERSION)
|
|
|
|
{
|
|
|
|
wcscpy(keyfound, keyname);
|
|
|
|
hKeyFound = hKeyTop[i];
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
# endif
|
|
|
|
}
|
|
|
|
RegCloseKey(hKey);
|
|
|
|
# ifdef USE_LIMITED_API
|
|
|
|
if (hKeyFound != NULL)
|
|
|
|
break;
|
|
|
|
# endif
|
|
|
|
}
|
|
|
|
if (hKeyFound == NULL)
|
2020-12-25 13:52:37 +01:00
|
|
|
return NULL;
|
2023-10-14 11:49:09 +02:00
|
|
|
|
|
|
|
swprintf(subkey, ARRAY_LENGTH(subkey), L"%ls\\%ls\\InstallPath",
|
|
|
|
pythoncore, keyfound);
|
|
|
|
ret = RegGetValueW(hKeyFound, subkey, NULL, RRF_RT_REG_SZ,
|
|
|
|
NULL, NULL, &len);
|
|
|
|
if (ret != ERROR_MORE_DATA && ret != ERROR_SUCCESS)
|
2020-12-25 13:52:37 +01:00
|
|
|
return NULL;
|
2023-10-14 11:49:09 +02:00
|
|
|
size_t len2 = len / sizeof(WCHAR) + 1 + strlen(libname);
|
|
|
|
WCHAR *path = alloc(len2 * sizeof(WCHAR));
|
|
|
|
if (path == NULL)
|
2020-12-25 13:52:37 +01:00
|
|
|
return NULL;
|
2023-10-14 11:49:09 +02:00
|
|
|
ret = RegGetValueW(hKeyFound, subkey, NULL, RRF_RT_REG_SZ,
|
|
|
|
NULL, path, &len);
|
|
|
|
if (ret != ERROR_SUCCESS)
|
|
|
|
{
|
|
|
|
vim_free(path);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
// Remove trailing path separators.
|
|
|
|
size_t len3 = wcslen(path);
|
|
|
|
if ((len3 > 0) && (path[len3 - 1] == L'/' || path[len3 - 1] == L'\\'))
|
|
|
|
--len3;
|
|
|
|
swprintf(path + len3, len2 - len3, L"\\%hs", libname);
|
|
|
|
return path;
|
2020-12-25 13:52:37 +01:00
|
|
|
}
|
|
|
|
# endif
|
|
|
|
|
2010-07-17 21:19:38 +02:00
|
|
|
/*
|
|
|
|
* Load library and get all pointers.
|
|
|
|
* Parameter 'libname' provides name of DLL.
|
|
|
|
* Return OK or FAIL.
|
|
|
|
*/
|
2010-07-24 23:51:45 +02:00
|
|
|
static int
|
|
|
|
py3_runtime_link_init(char *libname, int verbose)
|
2010-07-17 21:19:38 +02:00
|
|
|
{
|
|
|
|
int i;
|
2018-03-29 18:15:26 +02:00
|
|
|
PYTHON_PROC *ucs_from_string = (PYTHON_PROC *)&py3_PyUnicode_FromString;
|
|
|
|
PYTHON_PROC *ucs_decode = (PYTHON_PROC *)&py3_PyUnicode_Decode;
|
|
|
|
PYTHON_PROC *ucs_as_encoded_string =
|
|
|
|
(PYTHON_PROC *)&py3_PyUnicode_AsEncodedString;
|
2010-07-17 21:19:38 +02:00
|
|
|
|
2010-11-16 19:26:02 +01:00
|
|
|
# if !(defined(PY_NO_RTLD_GLOBAL) && defined(PY3_NO_RTLD_GLOBAL)) && defined(UNIX) && defined(FEAT_PYTHON)
|
2019-12-04 21:24:53 +01:00
|
|
|
// Can't have Python and Python3 loaded at the same time.
|
2021-12-27 17:21:41 +00:00
|
|
|
// It causes a crash, because RTLD_GLOBAL is needed for
|
2019-12-04 21:24:53 +01:00
|
|
|
// standard C extension libraries of one or both python versions.
|
2010-07-24 15:42:14 +02:00
|
|
|
if (python_loaded())
|
|
|
|
{
|
2011-08-28 16:00:19 +02:00
|
|
|
if (verbose)
|
2022-01-05 17:49:15 +00:00
|
|
|
emsg(_(e_this_vim_cannot_execute_py3_after_using_python));
|
2010-07-24 15:42:14 +02:00
|
|
|
return FAIL;
|
|
|
|
}
|
2010-08-09 22:06:13 +02:00
|
|
|
# endif
|
2010-07-24 15:42:14 +02:00
|
|
|
|
|
|
|
if (hinstPy3 != 0)
|
2010-07-17 23:52:29 +02:00
|
|
|
return OK;
|
2010-07-17 21:19:38 +02:00
|
|
|
hinstPy3 = load_dll(libname);
|
|
|
|
|
2020-12-25 13:52:37 +01:00
|
|
|
# ifdef MSWIN
|
|
|
|
if (!hinstPy3)
|
|
|
|
{
|
|
|
|
// Attempt to use the path from InstallPath as stored in the registry.
|
2023-10-14 11:49:09 +02:00
|
|
|
WCHAR *syslibname = py3_get_system_libname(libname);
|
2020-12-25 13:52:37 +01:00
|
|
|
|
|
|
|
if (syslibname != NULL)
|
|
|
|
{
|
2023-10-14 11:49:09 +02:00
|
|
|
hinstPy3 = LoadLibraryExW(syslibname, NULL,
|
|
|
|
LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR |
|
|
|
|
LOAD_LIBRARY_SEARCH_SYSTEM32);
|
2020-12-25 13:52:37 +01:00
|
|
|
vim_free(syslibname);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
# endif
|
|
|
|
|
2010-07-17 21:19:38 +02:00
|
|
|
if (!hinstPy3)
|
|
|
|
{
|
2010-07-17 23:52:29 +02:00
|
|
|
if (verbose)
|
2022-01-01 14:19:49 +00:00
|
|
|
semsg(_(e_could_not_load_library_str_str), libname, load_dll_error());
|
2010-07-17 23:52:29 +02:00
|
|
|
return FAIL;
|
2010-07-17 21:19:38 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; py3_funcname_table[i].ptr; ++i)
|
|
|
|
{
|
2010-07-17 23:52:29 +02:00
|
|
|
if ((*py3_funcname_table[i].ptr = symbol_from_dll(hinstPy3,
|
|
|
|
py3_funcname_table[i].name)) == NULL)
|
|
|
|
{
|
|
|
|
close_dll(hinstPy3);
|
|
|
|
hinstPy3 = 0;
|
|
|
|
if (verbose)
|
2022-01-01 14:19:49 +00:00
|
|
|
semsg(_(e_could_not_load_library_function_str), py3_funcname_table[i].name);
|
2010-07-17 23:52:29 +02:00
|
|
|
return FAIL;
|
|
|
|
}
|
2010-07-17 21:19:38 +02:00
|
|
|
}
|
|
|
|
|
2019-12-04 21:24:53 +01:00
|
|
|
// Load unicode functions separately as only the ucs2 or the ucs4 functions
|
|
|
|
// will be present in the library.
|
2012-10-23 05:17:37 +02:00
|
|
|
# if PY_VERSION_HEX >= 0x030300f0
|
2018-03-29 18:15:26 +02:00
|
|
|
*ucs_from_string = symbol_from_dll(hinstPy3, "PyUnicode_FromString");
|
|
|
|
*ucs_decode = symbol_from_dll(hinstPy3, "PyUnicode_Decode");
|
|
|
|
*ucs_as_encoded_string = symbol_from_dll(hinstPy3,
|
2012-10-14 03:22:56 +02:00
|
|
|
"PyUnicode_AsEncodedString");
|
2012-10-23 05:17:37 +02:00
|
|
|
# else
|
2018-03-29 18:15:26 +02:00
|
|
|
*ucs_from_string = symbol_from_dll(hinstPy3, "PyUnicodeUCS2_FromString");
|
|
|
|
*ucs_decode = symbol_from_dll(hinstPy3,
|
2011-06-19 00:27:51 +02:00
|
|
|
"PyUnicodeUCS2_Decode");
|
2018-03-29 18:15:26 +02:00
|
|
|
*ucs_as_encoded_string = symbol_from_dll(hinstPy3,
|
2011-06-19 00:27:51 +02:00
|
|
|
"PyUnicodeUCS2_AsEncodedString");
|
2018-03-29 18:15:26 +02:00
|
|
|
if (*ucs_from_string == NULL || *ucs_decode == NULL
|
|
|
|
|| *ucs_as_encoded_string == NULL)
|
2010-07-17 21:19:38 +02:00
|
|
|
{
|
2018-03-29 18:15:26 +02:00
|
|
|
*ucs_from_string = symbol_from_dll(hinstPy3,
|
2010-07-17 23:52:29 +02:00
|
|
|
"PyUnicodeUCS4_FromString");
|
2018-03-29 18:15:26 +02:00
|
|
|
*ucs_decode = symbol_from_dll(hinstPy3,
|
2011-06-19 00:27:51 +02:00
|
|
|
"PyUnicodeUCS4_Decode");
|
2018-03-29 18:15:26 +02:00
|
|
|
*ucs_as_encoded_string = symbol_from_dll(hinstPy3,
|
2011-06-19 00:27:51 +02:00
|
|
|
"PyUnicodeUCS4_AsEncodedString");
|
2010-07-17 21:19:38 +02:00
|
|
|
}
|
2012-10-23 05:17:37 +02:00
|
|
|
# endif
|
2018-03-29 18:15:26 +02:00
|
|
|
if (*ucs_from_string == NULL || *ucs_decode == NULL
|
|
|
|
|| *ucs_as_encoded_string == NULL)
|
2010-07-17 21:19:38 +02:00
|
|
|
{
|
2010-07-17 23:52:29 +02:00
|
|
|
close_dll(hinstPy3);
|
|
|
|
hinstPy3 = 0;
|
|
|
|
if (verbose)
|
2022-01-01 14:19:49 +00:00
|
|
|
semsg(_(e_could_not_load_library_function_str), "PyUnicode_UCSX_*");
|
2010-07-17 23:52:29 +02:00
|
|
|
return FAIL;
|
2010-07-17 21:19:38 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
return OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If python is enabled (there is installed python on Windows system) return
|
|
|
|
* TRUE, else FALSE.
|
|
|
|
*/
|
2010-07-24 23:51:45 +02:00
|
|
|
int
|
|
|
|
python3_enabled(int verbose)
|
2010-07-17 21:19:38 +02:00
|
|
|
{
|
2016-01-09 14:57:47 +01:00
|
|
|
return py3_runtime_link_init((char *)p_py3dll, verbose) == OK;
|
2010-07-17 21:19:38 +02:00
|
|
|
}
|
|
|
|
|
2019-12-04 21:24:53 +01:00
|
|
|
/*
|
|
|
|
* Load the standard Python exceptions - don't import the symbols from the
|
2010-07-17 21:19:38 +02:00
|
|
|
* DLL, as this can cause errors (importing data symbols is not reliable).
|
|
|
|
*/
|
2010-07-24 23:51:45 +02:00
|
|
|
static void
|
2016-01-30 17:24:07 +01:00
|
|
|
get_py3_exceptions(void)
|
2010-07-17 21:19:38 +02:00
|
|
|
{
|
|
|
|
PyObject *exmod = PyImport_ImportModule("builtins");
|
|
|
|
PyObject *exdict = PyModule_GetDict(exmod);
|
|
|
|
p3imp_PyExc_AttributeError = PyDict_GetItemString(exdict, "AttributeError");
|
|
|
|
p3imp_PyExc_IndexError = PyDict_GetItemString(exdict, "IndexError");
|
2013-04-24 13:04:26 +02:00
|
|
|
p3imp_PyExc_KeyError = PyDict_GetItemString(exdict, "KeyError");
|
2010-07-17 21:19:38 +02:00
|
|
|
p3imp_PyExc_KeyboardInterrupt = PyDict_GetItemString(exdict, "KeyboardInterrupt");
|
|
|
|
p3imp_PyExc_TypeError = PyDict_GetItemString(exdict, "TypeError");
|
|
|
|
p3imp_PyExc_ValueError = PyDict_GetItemString(exdict, "ValueError");
|
2013-07-01 22:03:04 +02:00
|
|
|
p3imp_PyExc_SystemExit = PyDict_GetItemString(exdict, "SystemExit");
|
2013-05-15 15:44:28 +02:00
|
|
|
p3imp_PyExc_RuntimeError = PyDict_GetItemString(exdict, "RuntimeError");
|
2013-06-10 21:27:29 +02:00
|
|
|
p3imp_PyExc_ImportError = PyDict_GetItemString(exdict, "ImportError");
|
2013-06-23 14:16:57 +02:00
|
|
|
p3imp_PyExc_OverflowError = PyDict_GetItemString(exdict, "OverflowError");
|
2010-07-17 21:19:38 +02:00
|
|
|
Py_XINCREF(p3imp_PyExc_AttributeError);
|
|
|
|
Py_XINCREF(p3imp_PyExc_IndexError);
|
2013-04-24 13:04:26 +02:00
|
|
|
Py_XINCREF(p3imp_PyExc_KeyError);
|
2010-07-17 21:19:38 +02:00
|
|
|
Py_XINCREF(p3imp_PyExc_KeyboardInterrupt);
|
|
|
|
Py_XINCREF(p3imp_PyExc_TypeError);
|
|
|
|
Py_XINCREF(p3imp_PyExc_ValueError);
|
2013-07-01 22:03:04 +02:00
|
|
|
Py_XINCREF(p3imp_PyExc_SystemExit);
|
2013-05-15 15:44:28 +02:00
|
|
|
Py_XINCREF(p3imp_PyExc_RuntimeError);
|
2013-06-10 21:27:29 +02:00
|
|
|
Py_XINCREF(p3imp_PyExc_ImportError);
|
2013-06-23 14:16:57 +02:00
|
|
|
Py_XINCREF(p3imp_PyExc_OverflowError);
|
2010-07-17 21:19:38 +02:00
|
|
|
Py_XDECREF(exmod);
|
|
|
|
}
|
2019-12-04 21:24:53 +01:00
|
|
|
#endif // DYNAMIC_PYTHON3
|
2010-07-17 21:19:38 +02:00
|
|
|
|
2012-06-29 12:54:53 +02:00
|
|
|
static int py3initialised = 0;
|
|
|
|
#define PYINITIALISED py3initialised
|
2017-07-07 14:50:44 +02:00
|
|
|
static int python_end_called = FALSE;
|
2012-06-29 12:54:53 +02:00
|
|
|
|
patch 9.0.1776: No support for stable Python 3 ABI
Problem: No support for stable Python 3 ABI
Solution: Support Python 3 stable ABI
Commits:
1) Support Python 3 stable ABI to allow mixed version interoperatbility
Vim currently supports embedding Python for use with plugins, and the
"dynamic" linking option allows the user to specify a locally installed
version of Python by setting `pythonthreedll`. However, one caveat is
that the Python 3 libs are not binary compatible across minor versions,
and mixing versions can potentially be dangerous (e.g. let's say Vim was
linked against the Python 3.10 SDK, but the user sets `pythonthreedll`
to a 3.11 lib). Usually, nothing bad happens, but in theory this could
lead to crashes, memory corruption, and other unpredictable behaviors.
It's also difficult for the user to tell something is wrong because Vim
has no way of reporting what Python 3 version Vim was linked with.
For Vim installed via a package manager, this usually isn't an issue
because all the dependencies would already be figured out. For prebuilt
Vim binaries like MacVim (my motivation for working on this), AppImage,
and Win32 installer this could potentially be an issue as usually a
single binary is distributed. This is more tricky when a new Python
version is released, as there's a chicken-and-egg issue with deciding
what Python version to build against and hard to keep in sync when a new
Python version just drops and we have a mix of users of different Python
versions, and a user just blindly upgrading to a new Python could lead to
bad interactions with Vim.
Python 3 does have a solution for this problem: stable ABI / limited API
(see https://docs.python.org/3/c-api/stable.html). The C SDK limits the
API to a set of functions that are promised to be stable across
versions. This pull request adds an ifdef config that allows us to turn
it on when building Vim. Vim binaries built with this option should be
safe to freely link with any Python 3 libraies without having the
constraint of having to use the same minor version.
Note: Python 2 has no such concept and this doesn't change how Python 2
integration works (not that there is going to be a new version of Python
2 that would cause compatibility issues in the future anyway).
---
Technical details:
======
The stable ABI can be accessed when we compile with the Python 3 limited
API (by defining `Py_LIMITED_API`). The Python 3 code (in `if_python3.c`
and `if_py_both.h`) would now handle this and switch to limited API
mode. Without it set, Vim will still use the full API as before so this
is an opt-in change.
The main difference is that `PyType_Object` is now an opaque struct that
we can't directly create "static types" out of, and we have to create
type objects as "heap types" instead. This is because the struct is not
stable and changes from version to version (e.g. 3.8 added a
`tp_vectorcall` field to it). I had to change all the types to be
allocated on the heap instead with just a pointer to them.
Other functions are also simply missing in limited API, or they are
introduced too late (e.g. `PyUnicode_AsUTF8AndSize` in 3.10) to it that
we need some other ways to do the same thing, so I had to abstract a few
things into macros, and sometimes re-implement functions like
`PyObject_NEW`.
One caveat is that in limited API, `OutputType` (used for replacing
`sys.stdout`) no longer inherits from `PyStdPrinter_Type` which I don't
think has any real issue other than minor differences in how they
convert to a string and missing a couple functions like `mode()` and
`fileno()`.
Also fixed an existing bug where `tp_basicsize` was set incorrectly for
`BufferObject`, `TabListObject, `WinListObject`.
Technically, there could be a small performance drop, there is a little
more indirection with accessing type objects, and some APIs like
`PyUnicode_AsUTF8AndSize` are missing, but in practice I didn't see any
difference, and any well-written Python plugin should try to avoid
excessing callbacks to the `vim` module in Python anyway.
I only tested limited API mode down to Python 3.7, which seemes to
compile and work fine. I haven't tried earlier Python versions.
2) Fix PyIter_Check on older Python vers / type##Ptr unused warning
For PyIter_Check, older versions exposed them as either macros (used in
full API), or a function (for use in limited API). A previous change
exposed PyIter_Check to the dynamic build because Python just moved it
to function-only in 3.10 anyway. Because of that, just make sure we
always grab the function in dynamic builds in earlier versions since
that's what Python eventually did anyway.
3) Move Py_LIMITED_API define to configure script
Can now use --with-python-stable-abi flag to customize what stable ABI
version to target. Can also use an env var to do so as well.
4) Show +python/dyn-stable in :version, and allow has() feature query
Not sure if the "/dyn-stable" suffix would break things, or whether we
should do it another way. Or just don't show it in version and rely on
has() feature checking.
5) Documentation first draft. Still need to implement v:python3_version
6) Fix PyIter_Check build breaks when compiling against Python 3.8
7) Add CI coverage stable ABI on Linux/Windows / make configurable on Windows
This adds configurable options for Windows make files (both MinGW and
MSVC). CI will also now exercise both traditional full API and stable
ABI for Linux and Windows in the matrix for coverage.
Also added a "dynamic" option to Linux matrix as a drive-by change to
make other scripting languages like Ruby / Perl testable under both
static and dynamic builds.
8) Fix inaccuracy in Windows docs
Python's own docs are confusing but you don't actually want to use
`python3.dll` for the dynamic linkage.
9) Add generated autoconf file
10) Add v:python3_version support
This variable indicates the version of Python3 that Vim was built
against (PY_VERSION_HEX), and will be useful to check whether the Python
library you are loading in dynamically actually fits it. When built with
stable ABI, it will be the limited ABI version instead
(`Py_LIMITED_API`), which indicates the minimum version of Python 3 the
user should have, rather than the exact match. When stable ABI is used,
we won't be exposing PY_VERSION_HEX in this var because it just doesn't
seem necessary to do so (the whole point of stable ABI is the promise
that it will work across versions), and I don't want to confuse the user
with too many variables.
Also, cleaned up some documentation, and added help tags.
11) Fix Python 3.7 compat issues
Fix a couple issues when using limited API < 3.8
- Crash on exit: In Python 3.7, if a heap-allocated type is destroyed
before all instances are, it would cause a crash later. This happens
when we destroyed `OptionsType` before calling `Py_Finalize` when
using the limited API. To make it worse, later versions changed the
semantics and now each instance has a strong reference to its own type
and the recommendation has changed to have each instance de-ref its
own type and have its type in GC traversal. To avoid dealing with
these cross-version variations, we just don't free the heap type. They
are static types in non-limited-API anyway and are designed to last
through the entirety of the app, and we also don't restart the Python
runtime and therefore do not need it to have absolutely 0 leaks.
See:
- https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-c-api
- https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api
- PyIter_Check: This function is not provided in limited APIs older than
3.8. Previously I was trying to mock it out using manual
PyType_GetSlot() but it was brittle and also does not actually work
properly for static types (it will generate a Python error). Just
return false. It does mean using limited API < 3.8 is not recommended
as you lose the functionality to handle iterators, but from playing
with plugins I couldn't find it to be an issue.
- Fix loading of PyIter_Check so it will be done when limited API < 3.8.
Otherwise loading a 3.7 Python lib will fail even if limited API was
specified to use it.
12) Make sure to only load `PyUnicode_AsUTF8AndSize` in needed in limited API
We don't use this function unless limited API >= 3.10, but we were
loading it regardless. Usually it's ok in Unix-like systems where Python
just has a single lib that we load from, but in Windows where there is a
separate python3.dll this would not work as the symbol would not have
been exposed in this more limited DLL file. This makes it much clearer
under what condition is this function needed.
closes: #12032
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
2023-08-20 21:18:38 +02:00
|
|
|
#ifdef USE_LIMITED_API
|
|
|
|
# define DESTRUCTOR_FINISH(self) \
|
2024-08-10 09:44:20 +02:00
|
|
|
((freefunc)PyType_GetSlot(Py_TYPE((PyObject*)self), Py_tp_free))((PyObject*)self)
|
patch 9.0.1776: No support for stable Python 3 ABI
Problem: No support for stable Python 3 ABI
Solution: Support Python 3 stable ABI
Commits:
1) Support Python 3 stable ABI to allow mixed version interoperatbility
Vim currently supports embedding Python for use with plugins, and the
"dynamic" linking option allows the user to specify a locally installed
version of Python by setting `pythonthreedll`. However, one caveat is
that the Python 3 libs are not binary compatible across minor versions,
and mixing versions can potentially be dangerous (e.g. let's say Vim was
linked against the Python 3.10 SDK, but the user sets `pythonthreedll`
to a 3.11 lib). Usually, nothing bad happens, but in theory this could
lead to crashes, memory corruption, and other unpredictable behaviors.
It's also difficult for the user to tell something is wrong because Vim
has no way of reporting what Python 3 version Vim was linked with.
For Vim installed via a package manager, this usually isn't an issue
because all the dependencies would already be figured out. For prebuilt
Vim binaries like MacVim (my motivation for working on this), AppImage,
and Win32 installer this could potentially be an issue as usually a
single binary is distributed. This is more tricky when a new Python
version is released, as there's a chicken-and-egg issue with deciding
what Python version to build against and hard to keep in sync when a new
Python version just drops and we have a mix of users of different Python
versions, and a user just blindly upgrading to a new Python could lead to
bad interactions with Vim.
Python 3 does have a solution for this problem: stable ABI / limited API
(see https://docs.python.org/3/c-api/stable.html). The C SDK limits the
API to a set of functions that are promised to be stable across
versions. This pull request adds an ifdef config that allows us to turn
it on when building Vim. Vim binaries built with this option should be
safe to freely link with any Python 3 libraies without having the
constraint of having to use the same minor version.
Note: Python 2 has no such concept and this doesn't change how Python 2
integration works (not that there is going to be a new version of Python
2 that would cause compatibility issues in the future anyway).
---
Technical details:
======
The stable ABI can be accessed when we compile with the Python 3 limited
API (by defining `Py_LIMITED_API`). The Python 3 code (in `if_python3.c`
and `if_py_both.h`) would now handle this and switch to limited API
mode. Without it set, Vim will still use the full API as before so this
is an opt-in change.
The main difference is that `PyType_Object` is now an opaque struct that
we can't directly create "static types" out of, and we have to create
type objects as "heap types" instead. This is because the struct is not
stable and changes from version to version (e.g. 3.8 added a
`tp_vectorcall` field to it). I had to change all the types to be
allocated on the heap instead with just a pointer to them.
Other functions are also simply missing in limited API, or they are
introduced too late (e.g. `PyUnicode_AsUTF8AndSize` in 3.10) to it that
we need some other ways to do the same thing, so I had to abstract a few
things into macros, and sometimes re-implement functions like
`PyObject_NEW`.
One caveat is that in limited API, `OutputType` (used for replacing
`sys.stdout`) no longer inherits from `PyStdPrinter_Type` which I don't
think has any real issue other than minor differences in how they
convert to a string and missing a couple functions like `mode()` and
`fileno()`.
Also fixed an existing bug where `tp_basicsize` was set incorrectly for
`BufferObject`, `TabListObject, `WinListObject`.
Technically, there could be a small performance drop, there is a little
more indirection with accessing type objects, and some APIs like
`PyUnicode_AsUTF8AndSize` are missing, but in practice I didn't see any
difference, and any well-written Python plugin should try to avoid
excessing callbacks to the `vim` module in Python anyway.
I only tested limited API mode down to Python 3.7, which seemes to
compile and work fine. I haven't tried earlier Python versions.
2) Fix PyIter_Check on older Python vers / type##Ptr unused warning
For PyIter_Check, older versions exposed them as either macros (used in
full API), or a function (for use in limited API). A previous change
exposed PyIter_Check to the dynamic build because Python just moved it
to function-only in 3.10 anyway. Because of that, just make sure we
always grab the function in dynamic builds in earlier versions since
that's what Python eventually did anyway.
3) Move Py_LIMITED_API define to configure script
Can now use --with-python-stable-abi flag to customize what stable ABI
version to target. Can also use an env var to do so as well.
4) Show +python/dyn-stable in :version, and allow has() feature query
Not sure if the "/dyn-stable" suffix would break things, or whether we
should do it another way. Or just don't show it in version and rely on
has() feature checking.
5) Documentation first draft. Still need to implement v:python3_version
6) Fix PyIter_Check build breaks when compiling against Python 3.8
7) Add CI coverage stable ABI on Linux/Windows / make configurable on Windows
This adds configurable options for Windows make files (both MinGW and
MSVC). CI will also now exercise both traditional full API and stable
ABI for Linux and Windows in the matrix for coverage.
Also added a "dynamic" option to Linux matrix as a drive-by change to
make other scripting languages like Ruby / Perl testable under both
static and dynamic builds.
8) Fix inaccuracy in Windows docs
Python's own docs are confusing but you don't actually want to use
`python3.dll` for the dynamic linkage.
9) Add generated autoconf file
10) Add v:python3_version support
This variable indicates the version of Python3 that Vim was built
against (PY_VERSION_HEX), and will be useful to check whether the Python
library you are loading in dynamically actually fits it. When built with
stable ABI, it will be the limited ABI version instead
(`Py_LIMITED_API`), which indicates the minimum version of Python 3 the
user should have, rather than the exact match. When stable ABI is used,
we won't be exposing PY_VERSION_HEX in this var because it just doesn't
seem necessary to do so (the whole point of stable ABI is the promise
that it will work across versions), and I don't want to confuse the user
with too many variables.
Also, cleaned up some documentation, and added help tags.
11) Fix Python 3.7 compat issues
Fix a couple issues when using limited API < 3.8
- Crash on exit: In Python 3.7, if a heap-allocated type is destroyed
before all instances are, it would cause a crash later. This happens
when we destroyed `OptionsType` before calling `Py_Finalize` when
using the limited API. To make it worse, later versions changed the
semantics and now each instance has a strong reference to its own type
and the recommendation has changed to have each instance de-ref its
own type and have its type in GC traversal. To avoid dealing with
these cross-version variations, we just don't free the heap type. They
are static types in non-limited-API anyway and are designed to last
through the entirety of the app, and we also don't restart the Python
runtime and therefore do not need it to have absolutely 0 leaks.
See:
- https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-c-api
- https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api
- PyIter_Check: This function is not provided in limited APIs older than
3.8. Previously I was trying to mock it out using manual
PyType_GetSlot() but it was brittle and also does not actually work
properly for static types (it will generate a Python error). Just
return false. It does mean using limited API < 3.8 is not recommended
as you lose the functionality to handle iterators, but from playing
with plugins I couldn't find it to be an issue.
- Fix loading of PyIter_Check so it will be done when limited API < 3.8.
Otherwise loading a 3.7 Python lib will fail even if limited API was
specified to use it.
12) Make sure to only load `PyUnicode_AsUTF8AndSize` in needed in limited API
We don't use this function unless limited API >= 3.10, but we were
loading it regardless. Usually it's ok in Unix-like systems where Python
just has a single lib that we load from, but in Windows where there is a
separate python3.dll this would not work as the symbol would not have
been exposed in this more limited DLL file. This makes it much clearer
under what condition is this function needed.
closes: #12032
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
2023-08-20 21:18:38 +02:00
|
|
|
#else
|
|
|
|
# define DESTRUCTOR_FINISH(self) Py_TYPE(self)->tp_free((PyObject*)self)
|
|
|
|
#endif
|
2012-06-29 12:54:53 +02:00
|
|
|
|
2013-05-12 18:44:48 +02:00
|
|
|
#define WIN_PYTHON_REF(win) win->w_python3_ref
|
|
|
|
#define BUF_PYTHON_REF(buf) buf->b_python3_ref
|
2013-05-15 15:12:29 +02:00
|
|
|
#define TAB_PYTHON_REF(tab) tab->tp_python3_ref
|
2013-05-12 18:44:48 +02:00
|
|
|
|
2010-07-24 23:51:45 +02:00
|
|
|
static void
|
|
|
|
call_PyObject_Free(void *p)
|
2010-07-17 21:19:38 +02:00
|
|
|
{
|
2013-05-29 21:33:39 +02:00
|
|
|
#if defined(Py_DEBUG) && !defined(Py_DEBUG_NO_PYMALLOC)
|
2010-07-17 21:19:38 +02:00
|
|
|
_PyObject_DebugFree(p);
|
|
|
|
#else
|
|
|
|
PyObject_Free(p);
|
|
|
|
#endif
|
|
|
|
}
|
2010-07-24 23:51:45 +02:00
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
call_PyType_GenericNew(PyTypeObject *type, PyObject *args, PyObject *kwds)
|
2010-07-17 21:19:38 +02:00
|
|
|
{
|
|
|
|
return PyType_GenericNew(type,args,kwds);
|
|
|
|
}
|
2010-07-24 23:51:45 +02:00
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
call_PyType_GenericAlloc(PyTypeObject *type, Py_ssize_t nitems)
|
2010-07-17 21:19:38 +02:00
|
|
|
{
|
|
|
|
return PyType_GenericAlloc(type,nitems);
|
|
|
|
}
|
|
|
|
|
2013-04-24 13:39:15 +02:00
|
|
|
static PyObject *OutputGetattro(PyObject *, PyObject *);
|
|
|
|
static int OutputSetattro(PyObject *, PyObject *, PyObject *);
|
|
|
|
static PyObject *BufferGetattro(PyObject *, PyObject *);
|
2013-05-29 22:02:22 +02:00
|
|
|
static int BufferSetattro(PyObject *, PyObject *, PyObject *);
|
2013-05-15 15:12:29 +02:00
|
|
|
static PyObject *TabPageGetattro(PyObject *, PyObject *);
|
2013-04-24 13:39:15 +02:00
|
|
|
static PyObject *WindowGetattro(PyObject *, PyObject *);
|
|
|
|
static int WindowSetattro(PyObject *, PyObject *, PyObject *);
|
|
|
|
static PyObject *RangeGetattro(PyObject *, PyObject *);
|
|
|
|
static PyObject *CurrentGetattro(PyObject *, PyObject *);
|
|
|
|
static int CurrentSetattro(PyObject *, PyObject *, PyObject *);
|
|
|
|
static PyObject *DictionaryGetattro(PyObject *, PyObject *);
|
|
|
|
static int DictionarySetattro(PyObject *, PyObject *, PyObject *);
|
|
|
|
static PyObject *ListGetattro(PyObject *, PyObject *);
|
|
|
|
static int ListSetattro(PyObject *, PyObject *, PyObject *);
|
|
|
|
static PyObject *FunctionGetattro(PyObject *, PyObject *);
|
|
|
|
|
|
|
|
static struct PyModuleDef vimmodule;
|
|
|
|
|
2013-05-21 22:23:56 +02:00
|
|
|
#define PY_CAN_RECURSE
|
|
|
|
|
2013-04-24 13:39:15 +02:00
|
|
|
/*
|
|
|
|
* Include the code shared with if_python.c
|
|
|
|
*/
|
|
|
|
#include "if_py_both.h"
|
|
|
|
|
2023-10-11 21:27:06 +02:00
|
|
|
#ifdef USE_LIMITED_API
|
patch 9.0.1776: No support for stable Python 3 ABI
Problem: No support for stable Python 3 ABI
Solution: Support Python 3 stable ABI
Commits:
1) Support Python 3 stable ABI to allow mixed version interoperatbility
Vim currently supports embedding Python for use with plugins, and the
"dynamic" linking option allows the user to specify a locally installed
version of Python by setting `pythonthreedll`. However, one caveat is
that the Python 3 libs are not binary compatible across minor versions,
and mixing versions can potentially be dangerous (e.g. let's say Vim was
linked against the Python 3.10 SDK, but the user sets `pythonthreedll`
to a 3.11 lib). Usually, nothing bad happens, but in theory this could
lead to crashes, memory corruption, and other unpredictable behaviors.
It's also difficult for the user to tell something is wrong because Vim
has no way of reporting what Python 3 version Vim was linked with.
For Vim installed via a package manager, this usually isn't an issue
because all the dependencies would already be figured out. For prebuilt
Vim binaries like MacVim (my motivation for working on this), AppImage,
and Win32 installer this could potentially be an issue as usually a
single binary is distributed. This is more tricky when a new Python
version is released, as there's a chicken-and-egg issue with deciding
what Python version to build against and hard to keep in sync when a new
Python version just drops and we have a mix of users of different Python
versions, and a user just blindly upgrading to a new Python could lead to
bad interactions with Vim.
Python 3 does have a solution for this problem: stable ABI / limited API
(see https://docs.python.org/3/c-api/stable.html). The C SDK limits the
API to a set of functions that are promised to be stable across
versions. This pull request adds an ifdef config that allows us to turn
it on when building Vim. Vim binaries built with this option should be
safe to freely link with any Python 3 libraies without having the
constraint of having to use the same minor version.
Note: Python 2 has no such concept and this doesn't change how Python 2
integration works (not that there is going to be a new version of Python
2 that would cause compatibility issues in the future anyway).
---
Technical details:
======
The stable ABI can be accessed when we compile with the Python 3 limited
API (by defining `Py_LIMITED_API`). The Python 3 code (in `if_python3.c`
and `if_py_both.h`) would now handle this and switch to limited API
mode. Without it set, Vim will still use the full API as before so this
is an opt-in change.
The main difference is that `PyType_Object` is now an opaque struct that
we can't directly create "static types" out of, and we have to create
type objects as "heap types" instead. This is because the struct is not
stable and changes from version to version (e.g. 3.8 added a
`tp_vectorcall` field to it). I had to change all the types to be
allocated on the heap instead with just a pointer to them.
Other functions are also simply missing in limited API, or they are
introduced too late (e.g. `PyUnicode_AsUTF8AndSize` in 3.10) to it that
we need some other ways to do the same thing, so I had to abstract a few
things into macros, and sometimes re-implement functions like
`PyObject_NEW`.
One caveat is that in limited API, `OutputType` (used for replacing
`sys.stdout`) no longer inherits from `PyStdPrinter_Type` which I don't
think has any real issue other than minor differences in how they
convert to a string and missing a couple functions like `mode()` and
`fileno()`.
Also fixed an existing bug where `tp_basicsize` was set incorrectly for
`BufferObject`, `TabListObject, `WinListObject`.
Technically, there could be a small performance drop, there is a little
more indirection with accessing type objects, and some APIs like
`PyUnicode_AsUTF8AndSize` are missing, but in practice I didn't see any
difference, and any well-written Python plugin should try to avoid
excessing callbacks to the `vim` module in Python anyway.
I only tested limited API mode down to Python 3.7, which seemes to
compile and work fine. I haven't tried earlier Python versions.
2) Fix PyIter_Check on older Python vers / type##Ptr unused warning
For PyIter_Check, older versions exposed them as either macros (used in
full API), or a function (for use in limited API). A previous change
exposed PyIter_Check to the dynamic build because Python just moved it
to function-only in 3.10 anyway. Because of that, just make sure we
always grab the function in dynamic builds in earlier versions since
that's what Python eventually did anyway.
3) Move Py_LIMITED_API define to configure script
Can now use --with-python-stable-abi flag to customize what stable ABI
version to target. Can also use an env var to do so as well.
4) Show +python/dyn-stable in :version, and allow has() feature query
Not sure if the "/dyn-stable" suffix would break things, or whether we
should do it another way. Or just don't show it in version and rely on
has() feature checking.
5) Documentation first draft. Still need to implement v:python3_version
6) Fix PyIter_Check build breaks when compiling against Python 3.8
7) Add CI coverage stable ABI on Linux/Windows / make configurable on Windows
This adds configurable options for Windows make files (both MinGW and
MSVC). CI will also now exercise both traditional full API and stable
ABI for Linux and Windows in the matrix for coverage.
Also added a "dynamic" option to Linux matrix as a drive-by change to
make other scripting languages like Ruby / Perl testable under both
static and dynamic builds.
8) Fix inaccuracy in Windows docs
Python's own docs are confusing but you don't actually want to use
`python3.dll` for the dynamic linkage.
9) Add generated autoconf file
10) Add v:python3_version support
This variable indicates the version of Python3 that Vim was built
against (PY_VERSION_HEX), and will be useful to check whether the Python
library you are loading in dynamically actually fits it. When built with
stable ABI, it will be the limited ABI version instead
(`Py_LIMITED_API`), which indicates the minimum version of Python 3 the
user should have, rather than the exact match. When stable ABI is used,
we won't be exposing PY_VERSION_HEX in this var because it just doesn't
seem necessary to do so (the whole point of stable ABI is the promise
that it will work across versions), and I don't want to confuse the user
with too many variables.
Also, cleaned up some documentation, and added help tags.
11) Fix Python 3.7 compat issues
Fix a couple issues when using limited API < 3.8
- Crash on exit: In Python 3.7, if a heap-allocated type is destroyed
before all instances are, it would cause a crash later. This happens
when we destroyed `OptionsType` before calling `Py_Finalize` when
using the limited API. To make it worse, later versions changed the
semantics and now each instance has a strong reference to its own type
and the recommendation has changed to have each instance de-ref its
own type and have its type in GC traversal. To avoid dealing with
these cross-version variations, we just don't free the heap type. They
are static types in non-limited-API anyway and are designed to last
through the entirety of the app, and we also don't restart the Python
runtime and therefore do not need it to have absolutely 0 leaks.
See:
- https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-c-api
- https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api
- PyIter_Check: This function is not provided in limited APIs older than
3.8. Previously I was trying to mock it out using manual
PyType_GetSlot() but it was brittle and also does not actually work
properly for static types (it will generate a Python error). Just
return false. It does mean using limited API < 3.8 is not recommended
as you lose the functionality to handle iterators, but from playing
with plugins I couldn't find it to be an issue.
- Fix loading of PyIter_Check so it will be done when limited API < 3.8.
Otherwise loading a 3.7 Python lib will fail even if limited API was
specified to use it.
12) Make sure to only load `PyUnicode_AsUTF8AndSize` in needed in limited API
We don't use this function unless limited API >= 3.10, but we were
loading it regardless. Usually it's ok in Unix-like systems where Python
just has a single lib that we load from, but in Windows where there is a
separate python3.dll this would not work as the symbol would not have
been exposed in this more limited DLL file. This makes it much clearer
under what condition is this function needed.
closes: #12032
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
2023-08-20 21:18:38 +02:00
|
|
|
# if Py_LIMITED_API >= 0x030A0000
|
|
|
|
# define PY_UNICODE_GET_UTF8_CHARS(obj) PyUnicode_AsUTF8AndSize(obj, NULL)
|
|
|
|
# else
|
|
|
|
// Python limited API before 3.10 lack easy ways to query the raw UTF-8 chars.
|
|
|
|
// We need to first convert the string to bytes, and then extract the chars.
|
|
|
|
// This function is only used for attribute string comparisons, which have
|
|
|
|
// known short length. As such, just allocate a short static buffer to hold
|
|
|
|
// the characters instead of having to allocate/deallcoate it.
|
|
|
|
//
|
|
|
|
// An alternative would be to convert all attribute string comparisons to use
|
|
|
|
// PyUnicode_CompareWithASCIIString to skip having to extract the chars.
|
|
|
|
static char py3_unicode_utf8_chars[20];
|
patch 9.0.1960: Make CI checks more strict
Problem: Make CI checks more strict
Solution: Add -Wstrict-prototypes -Wmissing-prototypes to CI,
fix uncovered problems
Add -Wstrict-prototypes -Wmissing-prototypes warnings check to CI
Add two new warnings to CI, silence some Perl related build-warnings:
- `strict-prototypes` helps prevent declaring a function with an empty
argument list, e.g. `int func()`. In C++, that's equivalent to `int
func(void)`, but in C, that means a function that can take any number
of arguments which is rarely what we want.
- `missing-prototypes` makes sure we use `static` for file-only internal
functions. Non-static functions should have been declared on a
prototype file.
- Add `no-compound-token-split-by-macro` to the perl cflags, since it
throws out a bunch of perl-related warnings that make the CI log
unnecessary verbose and hard to read. This seems to happen only with
clang 12 and above.
When applying those changes, it already uncovered a few warnings, so fix
up the code as well (fix prototypes, make the code static, remove
shadowed var declaration)
GTK header needs to have #pragma warning suppressiong because GTK2
headers will warn on `-Wstrict-prototypes`, and it's included by gui.h
and so we can't just turn off the warning in a couple files.
closes: #13223
closes: #13226
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
2023-09-30 12:28:50 +02:00
|
|
|
static char* PY_UNICODE_GET_UTF8_CHARS(PyObject* str)
|
patch 9.0.1776: No support for stable Python 3 ABI
Problem: No support for stable Python 3 ABI
Solution: Support Python 3 stable ABI
Commits:
1) Support Python 3 stable ABI to allow mixed version interoperatbility
Vim currently supports embedding Python for use with plugins, and the
"dynamic" linking option allows the user to specify a locally installed
version of Python by setting `pythonthreedll`. However, one caveat is
that the Python 3 libs are not binary compatible across minor versions,
and mixing versions can potentially be dangerous (e.g. let's say Vim was
linked against the Python 3.10 SDK, but the user sets `pythonthreedll`
to a 3.11 lib). Usually, nothing bad happens, but in theory this could
lead to crashes, memory corruption, and other unpredictable behaviors.
It's also difficult for the user to tell something is wrong because Vim
has no way of reporting what Python 3 version Vim was linked with.
For Vim installed via a package manager, this usually isn't an issue
because all the dependencies would already be figured out. For prebuilt
Vim binaries like MacVim (my motivation for working on this), AppImage,
and Win32 installer this could potentially be an issue as usually a
single binary is distributed. This is more tricky when a new Python
version is released, as there's a chicken-and-egg issue with deciding
what Python version to build against and hard to keep in sync when a new
Python version just drops and we have a mix of users of different Python
versions, and a user just blindly upgrading to a new Python could lead to
bad interactions with Vim.
Python 3 does have a solution for this problem: stable ABI / limited API
(see https://docs.python.org/3/c-api/stable.html). The C SDK limits the
API to a set of functions that are promised to be stable across
versions. This pull request adds an ifdef config that allows us to turn
it on when building Vim. Vim binaries built with this option should be
safe to freely link with any Python 3 libraies without having the
constraint of having to use the same minor version.
Note: Python 2 has no such concept and this doesn't change how Python 2
integration works (not that there is going to be a new version of Python
2 that would cause compatibility issues in the future anyway).
---
Technical details:
======
The stable ABI can be accessed when we compile with the Python 3 limited
API (by defining `Py_LIMITED_API`). The Python 3 code (in `if_python3.c`
and `if_py_both.h`) would now handle this and switch to limited API
mode. Without it set, Vim will still use the full API as before so this
is an opt-in change.
The main difference is that `PyType_Object` is now an opaque struct that
we can't directly create "static types" out of, and we have to create
type objects as "heap types" instead. This is because the struct is not
stable and changes from version to version (e.g. 3.8 added a
`tp_vectorcall` field to it). I had to change all the types to be
allocated on the heap instead with just a pointer to them.
Other functions are also simply missing in limited API, or they are
introduced too late (e.g. `PyUnicode_AsUTF8AndSize` in 3.10) to it that
we need some other ways to do the same thing, so I had to abstract a few
things into macros, and sometimes re-implement functions like
`PyObject_NEW`.
One caveat is that in limited API, `OutputType` (used for replacing
`sys.stdout`) no longer inherits from `PyStdPrinter_Type` which I don't
think has any real issue other than minor differences in how they
convert to a string and missing a couple functions like `mode()` and
`fileno()`.
Also fixed an existing bug where `tp_basicsize` was set incorrectly for
`BufferObject`, `TabListObject, `WinListObject`.
Technically, there could be a small performance drop, there is a little
more indirection with accessing type objects, and some APIs like
`PyUnicode_AsUTF8AndSize` are missing, but in practice I didn't see any
difference, and any well-written Python plugin should try to avoid
excessing callbacks to the `vim` module in Python anyway.
I only tested limited API mode down to Python 3.7, which seemes to
compile and work fine. I haven't tried earlier Python versions.
2) Fix PyIter_Check on older Python vers / type##Ptr unused warning
For PyIter_Check, older versions exposed them as either macros (used in
full API), or a function (for use in limited API). A previous change
exposed PyIter_Check to the dynamic build because Python just moved it
to function-only in 3.10 anyway. Because of that, just make sure we
always grab the function in dynamic builds in earlier versions since
that's what Python eventually did anyway.
3) Move Py_LIMITED_API define to configure script
Can now use --with-python-stable-abi flag to customize what stable ABI
version to target. Can also use an env var to do so as well.
4) Show +python/dyn-stable in :version, and allow has() feature query
Not sure if the "/dyn-stable" suffix would break things, or whether we
should do it another way. Or just don't show it in version and rely on
has() feature checking.
5) Documentation first draft. Still need to implement v:python3_version
6) Fix PyIter_Check build breaks when compiling against Python 3.8
7) Add CI coverage stable ABI on Linux/Windows / make configurable on Windows
This adds configurable options for Windows make files (both MinGW and
MSVC). CI will also now exercise both traditional full API and stable
ABI for Linux and Windows in the matrix for coverage.
Also added a "dynamic" option to Linux matrix as a drive-by change to
make other scripting languages like Ruby / Perl testable under both
static and dynamic builds.
8) Fix inaccuracy in Windows docs
Python's own docs are confusing but you don't actually want to use
`python3.dll` for the dynamic linkage.
9) Add generated autoconf file
10) Add v:python3_version support
This variable indicates the version of Python3 that Vim was built
against (PY_VERSION_HEX), and will be useful to check whether the Python
library you are loading in dynamically actually fits it. When built with
stable ABI, it will be the limited ABI version instead
(`Py_LIMITED_API`), which indicates the minimum version of Python 3 the
user should have, rather than the exact match. When stable ABI is used,
we won't be exposing PY_VERSION_HEX in this var because it just doesn't
seem necessary to do so (the whole point of stable ABI is the promise
that it will work across versions), and I don't want to confuse the user
with too many variables.
Also, cleaned up some documentation, and added help tags.
11) Fix Python 3.7 compat issues
Fix a couple issues when using limited API < 3.8
- Crash on exit: In Python 3.7, if a heap-allocated type is destroyed
before all instances are, it would cause a crash later. This happens
when we destroyed `OptionsType` before calling `Py_Finalize` when
using the limited API. To make it worse, later versions changed the
semantics and now each instance has a strong reference to its own type
and the recommendation has changed to have each instance de-ref its
own type and have its type in GC traversal. To avoid dealing with
these cross-version variations, we just don't free the heap type. They
are static types in non-limited-API anyway and are designed to last
through the entirety of the app, and we also don't restart the Python
runtime and therefore do not need it to have absolutely 0 leaks.
See:
- https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-c-api
- https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api
- PyIter_Check: This function is not provided in limited APIs older than
3.8. Previously I was trying to mock it out using manual
PyType_GetSlot() but it was brittle and also does not actually work
properly for static types (it will generate a Python error). Just
return false. It does mean using limited API < 3.8 is not recommended
as you lose the functionality to handle iterators, but from playing
with plugins I couldn't find it to be an issue.
- Fix loading of PyIter_Check so it will be done when limited API < 3.8.
Otherwise loading a 3.7 Python lib will fail even if limited API was
specified to use it.
12) Make sure to only load `PyUnicode_AsUTF8AndSize` in needed in limited API
We don't use this function unless limited API >= 3.10, but we were
loading it regardless. Usually it's ok in Unix-like systems where Python
just has a single lib that we load from, but in Windows where there is a
separate python3.dll this would not work as the symbol would not have
been exposed in this more limited DLL file. This makes it much clearer
under what condition is this function needed.
closes: #12032
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
2023-08-20 21:18:38 +02:00
|
|
|
{
|
|
|
|
py3_unicode_utf8_chars[0] = '\0';
|
|
|
|
PyObject* bytes = PyUnicode_AsUTF8String(str);
|
|
|
|
if (bytes)
|
|
|
|
{
|
|
|
|
char *chars;
|
|
|
|
Py_ssize_t len;
|
|
|
|
if (PyBytes_AsStringAndSize(bytes, &chars, &len) != -1)
|
|
|
|
{
|
|
|
|
if (len < (Py_ssize_t)sizeof(py3_unicode_utf8_chars))
|
|
|
|
// PyBytes_AsStringAndSize guarantees null-termination
|
|
|
|
memcpy(py3_unicode_utf8_chars, chars, len + 1);
|
|
|
|
}
|
|
|
|
Py_DECREF(bytes);
|
|
|
|
}
|
|
|
|
return py3_unicode_utf8_chars;
|
|
|
|
}
|
|
|
|
# endif
|
2023-10-11 21:27:06 +02:00
|
|
|
#else // !USE_LIMITED_API
|
|
|
|
# if PY_VERSION_HEX >= 0x030300f0
|
|
|
|
# define PY_UNICODE_GET_UTF8_CHARS(obj) PyUnicode_AsUTF8AndSize(obj, NULL)
|
|
|
|
# else
|
|
|
|
# define PY_UNICODE_GET_UTF8_CHARS _PyUnicode_AsString
|
|
|
|
# endif
|
patch 9.0.1776: No support for stable Python 3 ABI
Problem: No support for stable Python 3 ABI
Solution: Support Python 3 stable ABI
Commits:
1) Support Python 3 stable ABI to allow mixed version interoperatbility
Vim currently supports embedding Python for use with plugins, and the
"dynamic" linking option allows the user to specify a locally installed
version of Python by setting `pythonthreedll`. However, one caveat is
that the Python 3 libs are not binary compatible across minor versions,
and mixing versions can potentially be dangerous (e.g. let's say Vim was
linked against the Python 3.10 SDK, but the user sets `pythonthreedll`
to a 3.11 lib). Usually, nothing bad happens, but in theory this could
lead to crashes, memory corruption, and other unpredictable behaviors.
It's also difficult for the user to tell something is wrong because Vim
has no way of reporting what Python 3 version Vim was linked with.
For Vim installed via a package manager, this usually isn't an issue
because all the dependencies would already be figured out. For prebuilt
Vim binaries like MacVim (my motivation for working on this), AppImage,
and Win32 installer this could potentially be an issue as usually a
single binary is distributed. This is more tricky when a new Python
version is released, as there's a chicken-and-egg issue with deciding
what Python version to build against and hard to keep in sync when a new
Python version just drops and we have a mix of users of different Python
versions, and a user just blindly upgrading to a new Python could lead to
bad interactions with Vim.
Python 3 does have a solution for this problem: stable ABI / limited API
(see https://docs.python.org/3/c-api/stable.html). The C SDK limits the
API to a set of functions that are promised to be stable across
versions. This pull request adds an ifdef config that allows us to turn
it on when building Vim. Vim binaries built with this option should be
safe to freely link with any Python 3 libraies without having the
constraint of having to use the same minor version.
Note: Python 2 has no such concept and this doesn't change how Python 2
integration works (not that there is going to be a new version of Python
2 that would cause compatibility issues in the future anyway).
---
Technical details:
======
The stable ABI can be accessed when we compile with the Python 3 limited
API (by defining `Py_LIMITED_API`). The Python 3 code (in `if_python3.c`
and `if_py_both.h`) would now handle this and switch to limited API
mode. Without it set, Vim will still use the full API as before so this
is an opt-in change.
The main difference is that `PyType_Object` is now an opaque struct that
we can't directly create "static types" out of, and we have to create
type objects as "heap types" instead. This is because the struct is not
stable and changes from version to version (e.g. 3.8 added a
`tp_vectorcall` field to it). I had to change all the types to be
allocated on the heap instead with just a pointer to them.
Other functions are also simply missing in limited API, or they are
introduced too late (e.g. `PyUnicode_AsUTF8AndSize` in 3.10) to it that
we need some other ways to do the same thing, so I had to abstract a few
things into macros, and sometimes re-implement functions like
`PyObject_NEW`.
One caveat is that in limited API, `OutputType` (used for replacing
`sys.stdout`) no longer inherits from `PyStdPrinter_Type` which I don't
think has any real issue other than minor differences in how they
convert to a string and missing a couple functions like `mode()` and
`fileno()`.
Also fixed an existing bug where `tp_basicsize` was set incorrectly for
`BufferObject`, `TabListObject, `WinListObject`.
Technically, there could be a small performance drop, there is a little
more indirection with accessing type objects, and some APIs like
`PyUnicode_AsUTF8AndSize` are missing, but in practice I didn't see any
difference, and any well-written Python plugin should try to avoid
excessing callbacks to the `vim` module in Python anyway.
I only tested limited API mode down to Python 3.7, which seemes to
compile and work fine. I haven't tried earlier Python versions.
2) Fix PyIter_Check on older Python vers / type##Ptr unused warning
For PyIter_Check, older versions exposed them as either macros (used in
full API), or a function (for use in limited API). A previous change
exposed PyIter_Check to the dynamic build because Python just moved it
to function-only in 3.10 anyway. Because of that, just make sure we
always grab the function in dynamic builds in earlier versions since
that's what Python eventually did anyway.
3) Move Py_LIMITED_API define to configure script
Can now use --with-python-stable-abi flag to customize what stable ABI
version to target. Can also use an env var to do so as well.
4) Show +python/dyn-stable in :version, and allow has() feature query
Not sure if the "/dyn-stable" suffix would break things, or whether we
should do it another way. Or just don't show it in version and rely on
has() feature checking.
5) Documentation first draft. Still need to implement v:python3_version
6) Fix PyIter_Check build breaks when compiling against Python 3.8
7) Add CI coverage stable ABI on Linux/Windows / make configurable on Windows
This adds configurable options for Windows make files (both MinGW and
MSVC). CI will also now exercise both traditional full API and stable
ABI for Linux and Windows in the matrix for coverage.
Also added a "dynamic" option to Linux matrix as a drive-by change to
make other scripting languages like Ruby / Perl testable under both
static and dynamic builds.
8) Fix inaccuracy in Windows docs
Python's own docs are confusing but you don't actually want to use
`python3.dll` for the dynamic linkage.
9) Add generated autoconf file
10) Add v:python3_version support
This variable indicates the version of Python3 that Vim was built
against (PY_VERSION_HEX), and will be useful to check whether the Python
library you are loading in dynamically actually fits it. When built with
stable ABI, it will be the limited ABI version instead
(`Py_LIMITED_API`), which indicates the minimum version of Python 3 the
user should have, rather than the exact match. When stable ABI is used,
we won't be exposing PY_VERSION_HEX in this var because it just doesn't
seem necessary to do so (the whole point of stable ABI is the promise
that it will work across versions), and I don't want to confuse the user
with too many variables.
Also, cleaned up some documentation, and added help tags.
11) Fix Python 3.7 compat issues
Fix a couple issues when using limited API < 3.8
- Crash on exit: In Python 3.7, if a heap-allocated type is destroyed
before all instances are, it would cause a crash later. This happens
when we destroyed `OptionsType` before calling `Py_Finalize` when
using the limited API. To make it worse, later versions changed the
semantics and now each instance has a strong reference to its own type
and the recommendation has changed to have each instance de-ref its
own type and have its type in GC traversal. To avoid dealing with
these cross-version variations, we just don't free the heap type. They
are static types in non-limited-API anyway and are designed to last
through the entirety of the app, and we also don't restart the Python
runtime and therefore do not need it to have absolutely 0 leaks.
See:
- https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-c-api
- https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api
- PyIter_Check: This function is not provided in limited APIs older than
3.8. Previously I was trying to mock it out using manual
PyType_GetSlot() but it was brittle and also does not actually work
properly for static types (it will generate a Python error). Just
return false. It does mean using limited API < 3.8 is not recommended
as you lose the functionality to handle iterators, but from playing
with plugins I couldn't find it to be an issue.
- Fix loading of PyIter_Check so it will be done when limited API < 3.8.
Otherwise loading a 3.7 Python lib will fail even if limited API was
specified to use it.
12) Make sure to only load `PyUnicode_AsUTF8AndSize` in needed in limited API
We don't use this function unless limited API >= 3.10, but we were
loading it regardless. Usually it's ok in Unix-like systems where Python
just has a single lib that we load from, but in Windows where there is a
separate python3.dll this would not work as the symbol would not have
been exposed in this more limited DLL file. This makes it much clearer
under what condition is this function needed.
closes: #12032
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
2023-08-20 21:18:38 +02:00
|
|
|
#endif
|
|
|
|
|
2019-03-19 22:11:41 +01:00
|
|
|
// NOTE: Must always be used at the start of a block, since it declares "name".
|
2013-04-24 13:39:15 +02:00
|
|
|
#define GET_ATTR_STRING(name, nameobj) \
|
|
|
|
char *name = ""; \
|
|
|
|
if (PyUnicode_Check(nameobj)) \
|
patch 9.0.1776: No support for stable Python 3 ABI
Problem: No support for stable Python 3 ABI
Solution: Support Python 3 stable ABI
Commits:
1) Support Python 3 stable ABI to allow mixed version interoperatbility
Vim currently supports embedding Python for use with plugins, and the
"dynamic" linking option allows the user to specify a locally installed
version of Python by setting `pythonthreedll`. However, one caveat is
that the Python 3 libs are not binary compatible across minor versions,
and mixing versions can potentially be dangerous (e.g. let's say Vim was
linked against the Python 3.10 SDK, but the user sets `pythonthreedll`
to a 3.11 lib). Usually, nothing bad happens, but in theory this could
lead to crashes, memory corruption, and other unpredictable behaviors.
It's also difficult for the user to tell something is wrong because Vim
has no way of reporting what Python 3 version Vim was linked with.
For Vim installed via a package manager, this usually isn't an issue
because all the dependencies would already be figured out. For prebuilt
Vim binaries like MacVim (my motivation for working on this), AppImage,
and Win32 installer this could potentially be an issue as usually a
single binary is distributed. This is more tricky when a new Python
version is released, as there's a chicken-and-egg issue with deciding
what Python version to build against and hard to keep in sync when a new
Python version just drops and we have a mix of users of different Python
versions, and a user just blindly upgrading to a new Python could lead to
bad interactions with Vim.
Python 3 does have a solution for this problem: stable ABI / limited API
(see https://docs.python.org/3/c-api/stable.html). The C SDK limits the
API to a set of functions that are promised to be stable across
versions. This pull request adds an ifdef config that allows us to turn
it on when building Vim. Vim binaries built with this option should be
safe to freely link with any Python 3 libraies without having the
constraint of having to use the same minor version.
Note: Python 2 has no such concept and this doesn't change how Python 2
integration works (not that there is going to be a new version of Python
2 that would cause compatibility issues in the future anyway).
---
Technical details:
======
The stable ABI can be accessed when we compile with the Python 3 limited
API (by defining `Py_LIMITED_API`). The Python 3 code (in `if_python3.c`
and `if_py_both.h`) would now handle this and switch to limited API
mode. Without it set, Vim will still use the full API as before so this
is an opt-in change.
The main difference is that `PyType_Object` is now an opaque struct that
we can't directly create "static types" out of, and we have to create
type objects as "heap types" instead. This is because the struct is not
stable and changes from version to version (e.g. 3.8 added a
`tp_vectorcall` field to it). I had to change all the types to be
allocated on the heap instead with just a pointer to them.
Other functions are also simply missing in limited API, or they are
introduced too late (e.g. `PyUnicode_AsUTF8AndSize` in 3.10) to it that
we need some other ways to do the same thing, so I had to abstract a few
things into macros, and sometimes re-implement functions like
`PyObject_NEW`.
One caveat is that in limited API, `OutputType` (used for replacing
`sys.stdout`) no longer inherits from `PyStdPrinter_Type` which I don't
think has any real issue other than minor differences in how they
convert to a string and missing a couple functions like `mode()` and
`fileno()`.
Also fixed an existing bug where `tp_basicsize` was set incorrectly for
`BufferObject`, `TabListObject, `WinListObject`.
Technically, there could be a small performance drop, there is a little
more indirection with accessing type objects, and some APIs like
`PyUnicode_AsUTF8AndSize` are missing, but in practice I didn't see any
difference, and any well-written Python plugin should try to avoid
excessing callbacks to the `vim` module in Python anyway.
I only tested limited API mode down to Python 3.7, which seemes to
compile and work fine. I haven't tried earlier Python versions.
2) Fix PyIter_Check on older Python vers / type##Ptr unused warning
For PyIter_Check, older versions exposed them as either macros (used in
full API), or a function (for use in limited API). A previous change
exposed PyIter_Check to the dynamic build because Python just moved it
to function-only in 3.10 anyway. Because of that, just make sure we
always grab the function in dynamic builds in earlier versions since
that's what Python eventually did anyway.
3) Move Py_LIMITED_API define to configure script
Can now use --with-python-stable-abi flag to customize what stable ABI
version to target. Can also use an env var to do so as well.
4) Show +python/dyn-stable in :version, and allow has() feature query
Not sure if the "/dyn-stable" suffix would break things, or whether we
should do it another way. Or just don't show it in version and rely on
has() feature checking.
5) Documentation first draft. Still need to implement v:python3_version
6) Fix PyIter_Check build breaks when compiling against Python 3.8
7) Add CI coverage stable ABI on Linux/Windows / make configurable on Windows
This adds configurable options for Windows make files (both MinGW and
MSVC). CI will also now exercise both traditional full API and stable
ABI for Linux and Windows in the matrix for coverage.
Also added a "dynamic" option to Linux matrix as a drive-by change to
make other scripting languages like Ruby / Perl testable under both
static and dynamic builds.
8) Fix inaccuracy in Windows docs
Python's own docs are confusing but you don't actually want to use
`python3.dll` for the dynamic linkage.
9) Add generated autoconf file
10) Add v:python3_version support
This variable indicates the version of Python3 that Vim was built
against (PY_VERSION_HEX), and will be useful to check whether the Python
library you are loading in dynamically actually fits it. When built with
stable ABI, it will be the limited ABI version instead
(`Py_LIMITED_API`), which indicates the minimum version of Python 3 the
user should have, rather than the exact match. When stable ABI is used,
we won't be exposing PY_VERSION_HEX in this var because it just doesn't
seem necessary to do so (the whole point of stable ABI is the promise
that it will work across versions), and I don't want to confuse the user
with too many variables.
Also, cleaned up some documentation, and added help tags.
11) Fix Python 3.7 compat issues
Fix a couple issues when using limited API < 3.8
- Crash on exit: In Python 3.7, if a heap-allocated type is destroyed
before all instances are, it would cause a crash later. This happens
when we destroyed `OptionsType` before calling `Py_Finalize` when
using the limited API. To make it worse, later versions changed the
semantics and now each instance has a strong reference to its own type
and the recommendation has changed to have each instance de-ref its
own type and have its type in GC traversal. To avoid dealing with
these cross-version variations, we just don't free the heap type. They
are static types in non-limited-API anyway and are designed to last
through the entirety of the app, and we also don't restart the Python
runtime and therefore do not need it to have absolutely 0 leaks.
See:
- https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-c-api
- https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api
- PyIter_Check: This function is not provided in limited APIs older than
3.8. Previously I was trying to mock it out using manual
PyType_GetSlot() but it was brittle and also does not actually work
properly for static types (it will generate a Python error). Just
return false. It does mean using limited API < 3.8 is not recommended
as you lose the functionality to handle iterators, but from playing
with plugins I couldn't find it to be an issue.
- Fix loading of PyIter_Check so it will be done when limited API < 3.8.
Otherwise loading a 3.7 Python lib will fail even if limited API was
specified to use it.
12) Make sure to only load `PyUnicode_AsUTF8AndSize` in needed in limited API
We don't use this function unless limited API >= 3.10, but we were
loading it regardless. Usually it's ok in Unix-like systems where Python
just has a single lib that we load from, but in Windows where there is a
separate python3.dll this would not work as the symbol would not have
been exposed in this more limited DLL file. This makes it much clearer
under what condition is this function needed.
closes: #12032
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
2023-08-20 21:18:38 +02:00
|
|
|
name = (char *)PY_UNICODE_GET_UTF8_CHARS(nameobj)
|
2013-04-24 13:39:15 +02:00
|
|
|
|
|
|
|
#define PY3OBJ_DELETED(obj) (obj->ob_base.ob_refcnt<=0)
|
|
|
|
|
2019-12-04 21:24:53 +01:00
|
|
|
///////////////////////////////////////////////////////
|
|
|
|
// Internal function prototypes.
|
2010-07-17 21:19:38 +02:00
|
|
|
|
2012-11-28 15:33:14 +01:00
|
|
|
static PyObject *Py3Init_vim(void);
|
2010-07-17 21:19:38 +02:00
|
|
|
|
2019-12-04 21:24:53 +01:00
|
|
|
///////////////////////////////////////////////////////
|
|
|
|
// 1. Python interpreter main program.
|
2010-07-17 21:19:38 +02:00
|
|
|
|
2010-07-24 23:51:45 +02:00
|
|
|
void
|
2016-01-30 17:24:07 +01:00
|
|
|
python3_end(void)
|
2010-07-17 21:19:38 +02:00
|
|
|
{
|
|
|
|
static int recurse = 0;
|
|
|
|
|
2019-12-04 21:24:53 +01:00
|
|
|
// If a crash occurs while doing this, don't try again.
|
2010-07-17 21:19:38 +02:00
|
|
|
if (recurse != 0)
|
2010-07-17 23:52:29 +02:00
|
|
|
return;
|
2010-07-17 21:19:38 +02:00
|
|
|
|
2017-07-07 14:50:44 +02:00
|
|
|
python_end_called = TRUE;
|
2010-07-17 21:19:38 +02:00
|
|
|
++recurse;
|
|
|
|
|
|
|
|
#ifdef DYNAMIC_PYTHON3
|
|
|
|
if (hinstPy3)
|
|
|
|
#endif
|
|
|
|
if (Py_IsInitialized())
|
|
|
|
{
|
patch 9.0.1776: No support for stable Python 3 ABI
Problem: No support for stable Python 3 ABI
Solution: Support Python 3 stable ABI
Commits:
1) Support Python 3 stable ABI to allow mixed version interoperatbility
Vim currently supports embedding Python for use with plugins, and the
"dynamic" linking option allows the user to specify a locally installed
version of Python by setting `pythonthreedll`. However, one caveat is
that the Python 3 libs are not binary compatible across minor versions,
and mixing versions can potentially be dangerous (e.g. let's say Vim was
linked against the Python 3.10 SDK, but the user sets `pythonthreedll`
to a 3.11 lib). Usually, nothing bad happens, but in theory this could
lead to crashes, memory corruption, and other unpredictable behaviors.
It's also difficult for the user to tell something is wrong because Vim
has no way of reporting what Python 3 version Vim was linked with.
For Vim installed via a package manager, this usually isn't an issue
because all the dependencies would already be figured out. For prebuilt
Vim binaries like MacVim (my motivation for working on this), AppImage,
and Win32 installer this could potentially be an issue as usually a
single binary is distributed. This is more tricky when a new Python
version is released, as there's a chicken-and-egg issue with deciding
what Python version to build against and hard to keep in sync when a new
Python version just drops and we have a mix of users of different Python
versions, and a user just blindly upgrading to a new Python could lead to
bad interactions with Vim.
Python 3 does have a solution for this problem: stable ABI / limited API
(see https://docs.python.org/3/c-api/stable.html). The C SDK limits the
API to a set of functions that are promised to be stable across
versions. This pull request adds an ifdef config that allows us to turn
it on when building Vim. Vim binaries built with this option should be
safe to freely link with any Python 3 libraies without having the
constraint of having to use the same minor version.
Note: Python 2 has no such concept and this doesn't change how Python 2
integration works (not that there is going to be a new version of Python
2 that would cause compatibility issues in the future anyway).
---
Technical details:
======
The stable ABI can be accessed when we compile with the Python 3 limited
API (by defining `Py_LIMITED_API`). The Python 3 code (in `if_python3.c`
and `if_py_both.h`) would now handle this and switch to limited API
mode. Without it set, Vim will still use the full API as before so this
is an opt-in change.
The main difference is that `PyType_Object` is now an opaque struct that
we can't directly create "static types" out of, and we have to create
type objects as "heap types" instead. This is because the struct is not
stable and changes from version to version (e.g. 3.8 added a
`tp_vectorcall` field to it). I had to change all the types to be
allocated on the heap instead with just a pointer to them.
Other functions are also simply missing in limited API, or they are
introduced too late (e.g. `PyUnicode_AsUTF8AndSize` in 3.10) to it that
we need some other ways to do the same thing, so I had to abstract a few
things into macros, and sometimes re-implement functions like
`PyObject_NEW`.
One caveat is that in limited API, `OutputType` (used for replacing
`sys.stdout`) no longer inherits from `PyStdPrinter_Type` which I don't
think has any real issue other than minor differences in how they
convert to a string and missing a couple functions like `mode()` and
`fileno()`.
Also fixed an existing bug where `tp_basicsize` was set incorrectly for
`BufferObject`, `TabListObject, `WinListObject`.
Technically, there could be a small performance drop, there is a little
more indirection with accessing type objects, and some APIs like
`PyUnicode_AsUTF8AndSize` are missing, but in practice I didn't see any
difference, and any well-written Python plugin should try to avoid
excessing callbacks to the `vim` module in Python anyway.
I only tested limited API mode down to Python 3.7, which seemes to
compile and work fine. I haven't tried earlier Python versions.
2) Fix PyIter_Check on older Python vers / type##Ptr unused warning
For PyIter_Check, older versions exposed them as either macros (used in
full API), or a function (for use in limited API). A previous change
exposed PyIter_Check to the dynamic build because Python just moved it
to function-only in 3.10 anyway. Because of that, just make sure we
always grab the function in dynamic builds in earlier versions since
that's what Python eventually did anyway.
3) Move Py_LIMITED_API define to configure script
Can now use --with-python-stable-abi flag to customize what stable ABI
version to target. Can also use an env var to do so as well.
4) Show +python/dyn-stable in :version, and allow has() feature query
Not sure if the "/dyn-stable" suffix would break things, or whether we
should do it another way. Or just don't show it in version and rely on
has() feature checking.
5) Documentation first draft. Still need to implement v:python3_version
6) Fix PyIter_Check build breaks when compiling against Python 3.8
7) Add CI coverage stable ABI on Linux/Windows / make configurable on Windows
This adds configurable options for Windows make files (both MinGW and
MSVC). CI will also now exercise both traditional full API and stable
ABI for Linux and Windows in the matrix for coverage.
Also added a "dynamic" option to Linux matrix as a drive-by change to
make other scripting languages like Ruby / Perl testable under both
static and dynamic builds.
8) Fix inaccuracy in Windows docs
Python's own docs are confusing but you don't actually want to use
`python3.dll` for the dynamic linkage.
9) Add generated autoconf file
10) Add v:python3_version support
This variable indicates the version of Python3 that Vim was built
against (PY_VERSION_HEX), and will be useful to check whether the Python
library you are loading in dynamically actually fits it. When built with
stable ABI, it will be the limited ABI version instead
(`Py_LIMITED_API`), which indicates the minimum version of Python 3 the
user should have, rather than the exact match. When stable ABI is used,
we won't be exposing PY_VERSION_HEX in this var because it just doesn't
seem necessary to do so (the whole point of stable ABI is the promise
that it will work across versions), and I don't want to confuse the user
with too many variables.
Also, cleaned up some documentation, and added help tags.
11) Fix Python 3.7 compat issues
Fix a couple issues when using limited API < 3.8
- Crash on exit: In Python 3.7, if a heap-allocated type is destroyed
before all instances are, it would cause a crash later. This happens
when we destroyed `OptionsType` before calling `Py_Finalize` when
using the limited API. To make it worse, later versions changed the
semantics and now each instance has a strong reference to its own type
and the recommendation has changed to have each instance de-ref its
own type and have its type in GC traversal. To avoid dealing with
these cross-version variations, we just don't free the heap type. They
are static types in non-limited-API anyway and are designed to last
through the entirety of the app, and we also don't restart the Python
runtime and therefore do not need it to have absolutely 0 leaks.
See:
- https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-c-api
- https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api
- PyIter_Check: This function is not provided in limited APIs older than
3.8. Previously I was trying to mock it out using manual
PyType_GetSlot() but it was brittle and also does not actually work
properly for static types (it will generate a Python error). Just
return false. It does mean using limited API < 3.8 is not recommended
as you lose the functionality to handle iterators, but from playing
with plugins I couldn't find it to be an issue.
- Fix loading of PyIter_Check so it will be done when limited API < 3.8.
Otherwise loading a 3.7 Python lib will fail even if limited API was
specified to use it.
12) Make sure to only load `PyUnicode_AsUTF8AndSize` in needed in limited API
We don't use this function unless limited API >= 3.10, but we were
loading it regardless. Usually it's ok in Unix-like systems where Python
just has a single lib that we load from, but in Windows where there is a
separate python3.dll this would not work as the symbol would not have
been exposed in this more limited DLL file. This makes it much clearer
under what condition is this function needed.
closes: #12032
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
2023-08-20 21:18:38 +02:00
|
|
|
#ifdef USE_LIMITED_API
|
|
|
|
shutdown_types();
|
|
|
|
#endif
|
|
|
|
|
2019-12-04 21:24:53 +01:00
|
|
|
// acquire lock before finalizing
|
2013-05-15 17:49:05 +02:00
|
|
|
PyGILState_Ensure();
|
2010-07-17 21:19:38 +02:00
|
|
|
|
2010-07-17 23:52:29 +02:00
|
|
|
Py_Finalize();
|
2010-07-17 21:19:38 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
--recurse;
|
|
|
|
}
|
|
|
|
|
2015-10-07 10:39:55 +02:00
|
|
|
#if (defined(DYNAMIC_PYTHON3) && defined(DYNAMIC_PYTHON) && defined(FEAT_PYTHON) && defined(UNIX)) || defined(PROTO)
|
2010-07-24 15:42:14 +02:00
|
|
|
int
|
2016-01-30 17:24:07 +01:00
|
|
|
python3_loaded(void)
|
2010-07-24 15:42:14 +02:00
|
|
|
{
|
|
|
|
return (hinstPy3 != 0);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2018-01-31 21:49:05 +01:00
|
|
|
static wchar_t *py_home_buf = NULL;
|
|
|
|
|
2020-08-06 21:47:11 +02:00
|
|
|
#if defined(MSWIN) && (PY_VERSION_HEX >= 0x030500f0)
|
2020-10-10 23:26:28 +02:00
|
|
|
/*
|
|
|
|
* Return TRUE if stdin is readable from Python 3.
|
|
|
|
*/
|
|
|
|
static BOOL
|
|
|
|
is_stdin_readable(void)
|
|
|
|
{
|
|
|
|
DWORD mode, eventnum;
|
|
|
|
struct _stat st;
|
|
|
|
int fd = fileno(stdin);
|
|
|
|
HANDLE hstdin = (HANDLE)_get_osfhandle(fd);
|
|
|
|
|
|
|
|
// Check if stdin is connected to the console.
|
|
|
|
if (GetConsoleMode(hstdin, &mode))
|
|
|
|
// Check if it is opened as input.
|
|
|
|
return GetNumberOfConsoleInputEvents(hstdin, &eventnum);
|
|
|
|
|
|
|
|
return _fstat(fd, &st) == 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Python 3.5 or later will abort inside Py_Initialize() when stdin has
|
|
|
|
// been closed (i.e. executed by "vim -"). Reconnect stdin to CONIN$.
|
2020-08-06 21:47:11 +02:00
|
|
|
// Note that the python DLL is linked to its own stdio DLL which can be
|
|
|
|
// differ from Vim's stdio.
|
|
|
|
static void
|
|
|
|
reset_stdin(void)
|
|
|
|
{
|
|
|
|
FILE *(*py__acrt_iob_func)(unsigned) = NULL;
|
|
|
|
FILE *(*pyfreopen)(const char *, const char *, FILE *) = NULL;
|
2023-10-04 20:05:05 +02:00
|
|
|
HINSTANCE hinst = get_forwarded_dll(hinstPy3);
|
2020-08-06 21:47:11 +02:00
|
|
|
|
2020-10-10 23:26:28 +02:00
|
|
|
if (hinst == NULL || is_stdin_readable())
|
2020-08-06 21:47:11 +02:00
|
|
|
return;
|
|
|
|
|
|
|
|
// Get "freopen" and "stdin" which are used in the python DLL.
|
|
|
|
// "stdin" is defined as "__acrt_iob_func(0)" in VC++ 2015 or later.
|
|
|
|
py__acrt_iob_func = get_dll_import_func(hinst, "__acrt_iob_func");
|
|
|
|
if (py__acrt_iob_func)
|
|
|
|
{
|
|
|
|
HINSTANCE hpystdiodll = find_imported_module_by_funcname(hinst,
|
2020-10-06 19:59:06 +02:00
|
|
|
"__acrt_iob_func");
|
2020-08-06 21:47:11 +02:00
|
|
|
if (hpystdiodll)
|
2020-10-06 19:59:06 +02:00
|
|
|
pyfreopen = (void *)GetProcAddress(hpystdiodll, "freopen");
|
2020-08-06 21:47:11 +02:00
|
|
|
}
|
|
|
|
|
2020-10-10 23:26:28 +02:00
|
|
|
// Reconnect stdin to CONIN$.
|
2020-10-06 19:59:06 +02:00
|
|
|
if (pyfreopen != NULL)
|
2020-10-10 23:26:28 +02:00
|
|
|
pyfreopen("CONIN$", "r", py__acrt_iob_func(0));
|
2020-08-06 21:47:11 +02:00
|
|
|
else
|
2020-10-10 23:26:28 +02:00
|
|
|
freopen("CONIN$", "r", stdin);
|
2020-08-06 21:47:11 +02:00
|
|
|
}
|
|
|
|
#else
|
|
|
|
# define reset_stdin()
|
2022-02-07 13:54:01 +00:00
|
|
|
#endif
|
|
|
|
|
|
|
|
// Python 3.2 or later will abort inside Py_Initialize() when mandatory
|
|
|
|
// modules cannot be loaded (e.g. 'pythonthreehome' is wrongly set.).
|
|
|
|
// Install a hook to python dll's exit() and recover from it.
|
|
|
|
#if defined(MSWIN) && (PY_VERSION_HEX >= 0x030200f0)
|
|
|
|
# define HOOK_EXIT
|
|
|
|
# include <setjmp.h>
|
|
|
|
|
|
|
|
static jmp_buf exit_hook_jump_buf;
|
|
|
|
static void *orig_exit = NULL;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Function that replaces exit() while calling Py_Initialize().
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
hooked_exit(int ret)
|
|
|
|
{
|
|
|
|
// Recover from exit.
|
|
|
|
longjmp(exit_hook_jump_buf, 1);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Install a hook to python dll's exit().
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
hook_py_exit(void)
|
|
|
|
{
|
2023-10-04 20:05:05 +02:00
|
|
|
HINSTANCE hinst = get_forwarded_dll(hinstPy3);
|
2022-02-07 13:54:01 +00:00
|
|
|
|
|
|
|
if (hinst == NULL || orig_exit != NULL)
|
|
|
|
return;
|
|
|
|
|
|
|
|
orig_exit = hook_dll_import_func(hinst, "exit", (void *)hooked_exit);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Remove the hook installed by hook_py_exit().
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
restore_py_exit(void)
|
|
|
|
{
|
|
|
|
HINSTANCE hinst = hinstPy3;
|
|
|
|
|
|
|
|
if (hinst == NULL)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (orig_exit != NULL)
|
|
|
|
hook_dll_import_func(hinst, "exit", orig_exit);
|
|
|
|
orig_exit = NULL;
|
|
|
|
}
|
2020-08-06 21:47:11 +02:00
|
|
|
#endif
|
|
|
|
|
2010-07-24 23:51:45 +02:00
|
|
|
static int
|
|
|
|
Python3_Init(void)
|
2010-07-17 21:19:38 +02:00
|
|
|
{
|
|
|
|
if (!py3initialised)
|
|
|
|
{
|
|
|
|
#ifdef DYNAMIC_PYTHON3
|
2010-07-17 23:52:29 +02:00
|
|
|
if (!python3_enabled(TRUE))
|
|
|
|
{
|
2022-01-01 21:59:18 +00:00
|
|
|
emsg(_(e_sorry_this_command_is_disabled_python_library_could_not_be_found));
|
2010-07-17 23:52:29 +02:00
|
|
|
goto fail;
|
|
|
|
}
|
2010-07-17 21:19:38 +02:00
|
|
|
#endif
|
2024-10-14 20:28:39 +02:00
|
|
|
// Python 3.13 introduced a really useful feature: colorized exceptions.
|
|
|
|
// This is great if you're reading them from the terminal, but useless
|
|
|
|
// and broken everywhere else (such as in log files, or text editors).
|
|
|
|
// Opt out, forcefully.
|
|
|
|
vim_setenv((char_u*)"PYTHON_COLORS", (char_u*)"0");
|
2010-07-17 21:19:38 +02:00
|
|
|
|
|
|
|
init_structs();
|
|
|
|
|
2018-01-31 21:49:05 +01:00
|
|
|
if (*p_py3home != NUL)
|
|
|
|
{
|
|
|
|
size_t len = mbstowcs(NULL, (char *)p_py3home, 0) + 1;
|
2010-11-16 19:26:02 +01:00
|
|
|
|
2019-12-04 21:24:53 +01:00
|
|
|
// The string must not change later, make a copy in static memory.
|
2019-05-28 23:08:19 +02:00
|
|
|
py_home_buf = ALLOC_MULT(wchar_t, len);
|
2018-01-31 21:49:05 +01:00
|
|
|
if (py_home_buf != NULL && mbstowcs(
|
|
|
|
py_home_buf, (char *)p_py3home, len) != (size_t)-1)
|
|
|
|
Py_SetPythonHome(py_home_buf);
|
|
|
|
}
|
2010-11-16 19:26:02 +01:00
|
|
|
#ifdef PYTHON3_HOME
|
2018-01-31 21:49:05 +01:00
|
|
|
else if (mch_getenv((char_u *)"PYTHONHOME") == NULL)
|
2015-12-31 21:03:23 +01:00
|
|
|
Py_SetPythonHome(PYTHON3_HOME);
|
2010-11-16 19:26:02 +01:00
|
|
|
#endif
|
|
|
|
|
2012-10-14 03:22:56 +02:00
|
|
|
PyImport_AppendInittab("vim", Py3Init_vim);
|
|
|
|
|
2022-02-07 13:54:01 +00:00
|
|
|
#if !defined(DYNAMIC_PYTHON3) && defined(MSWIN)
|
|
|
|
hinstPy3 = GetModuleHandle(PYTHON3_DLL);
|
|
|
|
#endif
|
2020-08-06 21:47:11 +02:00
|
|
|
reset_stdin();
|
2022-02-07 13:54:01 +00:00
|
|
|
|
|
|
|
#ifdef HOOK_EXIT
|
|
|
|
// Catch exit() called in Py_Initialize().
|
|
|
|
hook_py_exit();
|
|
|
|
if (setjmp(exit_hook_jump_buf) == 0)
|
|
|
|
{
|
|
|
|
Py_Initialize();
|
|
|
|
restore_py_exit();
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
// exit() was called in Py_Initialize().
|
|
|
|
restore_py_exit();
|
|
|
|
emsg(_(e_critical_error_in_python3_initialization_check_your_installation));
|
|
|
|
goto fail;
|
|
|
|
}
|
2022-12-26 14:46:51 +00:00
|
|
|
#else
|
|
|
|
Py_Initialize();
|
2022-02-07 13:54:01 +00:00
|
|
|
#endif
|
2017-10-28 21:11:06 +02:00
|
|
|
|
2020-10-11 18:05:02 +02:00
|
|
|
#if PY_VERSION_HEX < 0x03090000
|
|
|
|
// Initialise threads. This is deprecated since Python 3.9.
|
2011-06-12 21:37:13 +02:00
|
|
|
PyEval_InitThreads();
|
2020-10-11 18:05:02 +02:00
|
|
|
#endif
|
2010-07-17 21:19:38 +02:00
|
|
|
#ifdef DYNAMIC_PYTHON3
|
2010-07-17 23:52:29 +02:00
|
|
|
get_py3_exceptions();
|
2010-07-17 21:19:38 +02:00
|
|
|
#endif
|
|
|
|
|
2013-05-21 19:11:01 +02:00
|
|
|
if (PythonIO_Init_io())
|
2010-07-17 23:52:29 +02:00
|
|
|
goto fail;
|
2010-07-17 21:19:38 +02:00
|
|
|
|
2012-06-29 12:54:53 +02:00
|
|
|
globals = PyModule_GetDict(PyImport_AddModule("__main__"));
|
|
|
|
|
2019-12-04 21:24:53 +01:00
|
|
|
// Remove the element from sys.path that was added because of our
|
|
|
|
// argv[0] value in Py3Init_vim(). Previously we used an empty
|
|
|
|
// string, but depending on the OS we then get an empty entry or
|
|
|
|
// the current directory in sys.path.
|
|
|
|
// Only after vim has been imported, the element does exist in
|
|
|
|
// sys.path.
|
2011-06-19 00:27:51 +02:00
|
|
|
PyRun_SimpleString("import vim; import sys; sys.path = list(filter(lambda x: not x.endswith('must>not&exist'), sys.path))");
|
2010-07-17 21:19:38 +02:00
|
|
|
|
2020-10-11 18:05:02 +02:00
|
|
|
// Without the call to PyEval_SaveThread, thread specific state (such
|
|
|
|
// as the system trace hook), will be lost between invocations of
|
|
|
|
// Python code.
|
|
|
|
// GIL may have been created and acquired in PyEval_InitThreads() and
|
|
|
|
// thread state is created in Py_Initialize(); there
|
|
|
|
// _PyGILState_NoteThreadState() also sets gilcounter to 1 (python must
|
|
|
|
// have threads enabled!), so the following does both: unlock GIL and
|
|
|
|
// save thread state in TLS without deleting thread state
|
2013-02-13 14:17:08 +01:00
|
|
|
PyEval_SaveThread();
|
2010-07-17 21:19:38 +02:00
|
|
|
|
2010-07-17 23:52:29 +02:00
|
|
|
py3initialised = 1;
|
2010-07-17 21:19:38 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
fail:
|
2019-12-04 21:24:53 +01:00
|
|
|
// We call PythonIO_Flush() here to print any Python errors.
|
|
|
|
// This is OK, as it is possible to call this function even
|
|
|
|
// if PythonIO_Init_io() has not completed successfully (it will
|
|
|
|
// not do anything in this case).
|
2010-07-17 21:19:38 +02:00
|
|
|
PythonIO_Flush();
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* External interface
|
|
|
|
*/
|
2010-07-24 23:51:45 +02:00
|
|
|
static void
|
2024-11-06 21:50:05 +01:00
|
|
|
DoPyCommand(const char *cmd,
|
|
|
|
dict_T* locals,
|
|
|
|
rangeinitializer init_range,
|
|
|
|
runner run,
|
|
|
|
void *arg)
|
2010-07-17 21:19:38 +02:00
|
|
|
{
|
|
|
|
#if defined(HAVE_LOCALE_H) || defined(X_LOCALE)
|
2010-07-17 23:52:29 +02:00
|
|
|
char *saved_locale;
|
2010-07-17 21:19:38 +02:00
|
|
|
#endif
|
2011-06-19 00:27:51 +02:00
|
|
|
PyObject *cmdstr;
|
|
|
|
PyObject *cmdbytes;
|
2013-05-15 17:49:05 +02:00
|
|
|
PyGILState_STATE pygilstate;
|
2010-07-17 21:19:38 +02:00
|
|
|
|
2017-07-07 14:50:44 +02:00
|
|
|
if (python_end_called)
|
|
|
|
goto theend;
|
|
|
|
|
2010-07-17 21:19:38 +02:00
|
|
|
if (Python3_Init())
|
2010-07-17 23:52:29 +02:00
|
|
|
goto theend;
|
2010-07-17 21:19:38 +02:00
|
|
|
|
2013-05-21 18:19:38 +02:00
|
|
|
init_range(arg);
|
|
|
|
|
2019-12-04 21:24:53 +01:00
|
|
|
Python_Release_Vim(); // leave Vim
|
2010-07-17 21:19:38 +02:00
|
|
|
|
|
|
|
#if defined(HAVE_LOCALE_H) || defined(X_LOCALE)
|
2019-12-04 21:24:53 +01:00
|
|
|
// Python only works properly when the LC_NUMERIC locale is "C".
|
2010-07-17 21:19:38 +02:00
|
|
|
saved_locale = setlocale(LC_NUMERIC, NULL);
|
|
|
|
if (saved_locale == NULL || STRCMP(saved_locale, "C") == 0)
|
2010-07-17 23:52:29 +02:00
|
|
|
saved_locale = NULL;
|
2010-07-17 21:19:38 +02:00
|
|
|
else
|
|
|
|
{
|
2019-12-04 21:24:53 +01:00
|
|
|
// Need to make a copy, value may change when setting new locale.
|
2010-07-17 23:52:29 +02:00
|
|
|
saved_locale = (char *)vim_strsave((char_u *)saved_locale);
|
|
|
|
(void)setlocale(LC_NUMERIC, "C");
|
2010-07-17 21:19:38 +02:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
pygilstate = PyGILState_Ensure();
|
|
|
|
|
2019-12-04 21:24:53 +01:00
|
|
|
// PyRun_SimpleString expects a UTF-8 string. Wrong encoding may cause
|
|
|
|
// SyntaxError (unicode error).
|
2011-07-15 15:54:44 +02:00
|
|
|
cmdstr = PyUnicode_Decode(cmd, strlen(cmd),
|
2020-12-21 16:03:02 +01:00
|
|
|
(char *)ENC_OPT, ERRORS_DECODE_ARG);
|
|
|
|
cmdbytes = PyUnicode_AsEncodedString(cmdstr, "utf-8", ERRORS_ENCODE_ARG);
|
2011-06-19 00:27:51 +02:00
|
|
|
Py_XDECREF(cmdstr);
|
2012-06-29 12:54:53 +02:00
|
|
|
|
2024-11-06 21:50:05 +01:00
|
|
|
run(PyBytes_AsString(cmdbytes), locals, arg, &pygilstate);
|
2011-06-19 00:27:51 +02:00
|
|
|
Py_XDECREF(cmdbytes);
|
2010-07-17 21:19:38 +02:00
|
|
|
|
|
|
|
PyGILState_Release(pygilstate);
|
|
|
|
|
|
|
|
#if defined(HAVE_LOCALE_H) || defined(X_LOCALE)
|
|
|
|
if (saved_locale != NULL)
|
|
|
|
{
|
2010-07-17 23:52:29 +02:00
|
|
|
(void)setlocale(LC_NUMERIC, saved_locale);
|
|
|
|
vim_free(saved_locale);
|
2010-07-17 21:19:38 +02:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2019-12-04 21:24:53 +01:00
|
|
|
Python_Lock_Vim(); // enter Vim
|
2010-07-17 21:19:38 +02:00
|
|
|
PythonIO_Flush();
|
|
|
|
|
|
|
|
theend:
|
2019-12-04 21:24:53 +01:00
|
|
|
return; // keeps lint happy
|
2010-07-17 21:19:38 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2010-07-19 20:46:22 +02:00
|
|
|
* ":py3"
|
2010-07-17 21:19:38 +02:00
|
|
|
*/
|
2010-07-24 23:51:45 +02:00
|
|
|
void
|
|
|
|
ex_py3(exarg_T *eap)
|
2010-07-17 21:19:38 +02:00
|
|
|
{
|
|
|
|
char_u *script;
|
|
|
|
|
|
|
|
script = script_get(eap, eap->arg);
|
|
|
|
if (!eap->skip)
|
|
|
|
{
|
2019-02-18 22:04:56 +01:00
|
|
|
if (p_pyx == 0)
|
|
|
|
p_pyx = 3;
|
|
|
|
|
2013-05-21 18:19:38 +02:00
|
|
|
DoPyCommand(script == NULL ? (char *) eap->arg : (char *) script,
|
2024-11-06 21:50:05 +01:00
|
|
|
NULL,
|
2023-09-19 20:30:22 +02:00
|
|
|
init_range_cmd,
|
2013-05-21 18:19:38 +02:00
|
|
|
(runner) run_cmd,
|
|
|
|
(void *) eap);
|
2010-07-17 21:19:38 +02:00
|
|
|
}
|
|
|
|
vim_free(script);
|
|
|
|
}
|
|
|
|
|
|
|
|
#define BUFFER_SIZE 2048
|
|
|
|
|
|
|
|
/*
|
2010-07-18 18:04:50 +02:00
|
|
|
* ":py3file"
|
2010-07-17 21:19:38 +02:00
|
|
|
*/
|
|
|
|
void
|
|
|
|
ex_py3file(exarg_T *eap)
|
|
|
|
{
|
|
|
|
static char buffer[BUFFER_SIZE];
|
|
|
|
const char *file;
|
|
|
|
char *p;
|
|
|
|
int i;
|
|
|
|
|
2017-01-28 16:06:38 +01:00
|
|
|
if (p_pyx == 0)
|
|
|
|
p_pyx = 3;
|
|
|
|
|
2019-12-04 21:24:53 +01:00
|
|
|
// Have to do it like this. PyRun_SimpleFile requires you to pass a
|
|
|
|
// stdio file pointer, but Vim and the Python DLL are compiled with
|
|
|
|
// different options under Windows, meaning that stdio pointers aren't
|
|
|
|
// compatible between the two. Yuk.
|
|
|
|
//
|
|
|
|
// construct: exec(compile(open('a_filename', 'rb').read(), 'a_filename', 'exec'))
|
|
|
|
//
|
|
|
|
// Using bytes so that Python can detect the source encoding as it normally
|
|
|
|
// does. The doc does not say "compile" accept bytes, though.
|
|
|
|
//
|
|
|
|
// We need to escape any backslashes or single quotes in the file name, so that
|
|
|
|
// Python won't mangle the file name.
|
2010-07-17 21:19:38 +02:00
|
|
|
|
|
|
|
strcpy(buffer, "exec(compile(open('");
|
2019-12-04 21:24:53 +01:00
|
|
|
p = buffer + 19; // size of "exec(compile(open('"
|
2010-07-17 21:19:38 +02:00
|
|
|
|
|
|
|
for (i=0; i<2; ++i)
|
|
|
|
{
|
2010-07-17 23:52:29 +02:00
|
|
|
file = (char *)eap->arg;
|
|
|
|
while (*file && p < buffer + (BUFFER_SIZE - 3))
|
|
|
|
{
|
|
|
|
if (*file == '\\' || *file == '\'')
|
|
|
|
*p++ = '\\';
|
|
|
|
*p++ = *file++;
|
|
|
|
}
|
2019-12-04 21:24:53 +01:00
|
|
|
// If we didn't finish the file name, we hit a buffer overflow
|
2010-07-17 23:52:29 +02:00
|
|
|
if (*file != '\0')
|
|
|
|
return;
|
|
|
|
if (i==0)
|
|
|
|
{
|
2011-06-19 00:27:51 +02:00
|
|
|
strcpy(p,"','rb').read(),'");
|
|
|
|
p += 16;
|
2010-07-17 23:52:29 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
strcpy(p,"','exec'))");
|
|
|
|
p += 10;
|
|
|
|
}
|
2010-07-17 21:19:38 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2019-12-04 21:24:53 +01:00
|
|
|
// Execute the file
|
2013-05-21 18:19:38 +02:00
|
|
|
DoPyCommand(buffer,
|
2024-11-06 21:50:05 +01:00
|
|
|
NULL,
|
2023-09-19 20:30:22 +02:00
|
|
|
init_range_cmd,
|
2013-05-21 18:19:38 +02:00
|
|
|
(runner) run_cmd,
|
|
|
|
(void *) eap);
|
2010-07-17 21:19:38 +02:00
|
|
|
}
|
|
|
|
|
2013-05-15 19:44:39 +02:00
|
|
|
void
|
|
|
|
ex_py3do(exarg_T *eap)
|
2013-05-15 18:28:13 +02:00
|
|
|
{
|
2017-01-28 16:06:38 +01:00
|
|
|
if (p_pyx == 0)
|
|
|
|
p_pyx = 3;
|
|
|
|
|
2013-05-21 18:19:38 +02:00
|
|
|
DoPyCommand((char *)eap->arg,
|
2024-11-06 21:50:05 +01:00
|
|
|
NULL,
|
2023-09-19 20:30:22 +02:00
|
|
|
init_range_cmd,
|
2013-05-21 18:19:38 +02:00
|
|
|
(runner)run_do,
|
|
|
|
(void *)eap);
|
2013-05-15 18:28:13 +02:00
|
|
|
}
|
|
|
|
|
2019-12-04 21:24:53 +01:00
|
|
|
///////////////////////////////////////////////////////
|
|
|
|
// 2. Python output stream: writes output via [e]msg().
|
2010-07-17 21:19:38 +02:00
|
|
|
|
2019-12-04 21:24:53 +01:00
|
|
|
// Implementation functions
|
2010-07-17 21:19:38 +02:00
|
|
|
|
2010-07-24 23:51:45 +02:00
|
|
|
static PyObject *
|
|
|
|
OutputGetattro(PyObject *self, PyObject *nameobj)
|
2010-07-17 21:19:38 +02:00
|
|
|
{
|
2012-09-21 13:46:06 +02:00
|
|
|
GET_ATTR_STRING(name, nameobj);
|
2010-07-17 21:19:38 +02:00
|
|
|
|
|
|
|
if (strcmp(name, "softspace") == 0)
|
2010-07-17 23:52:29 +02:00
|
|
|
return PyLong_FromLong(((OutputObject *)(self))->softspace);
|
2016-04-21 20:00:56 +02:00
|
|
|
else if (strcmp(name, "errors") == 0)
|
|
|
|
return PyString_FromString("strict");
|
|
|
|
else if (strcmp(name, "encoding") == 0)
|
|
|
|
return PyString_FromString(ENC_OPT);
|
2010-07-17 21:19:38 +02:00
|
|
|
|
|
|
|
return PyObject_GenericGetAttr(self, nameobj);
|
|
|
|
}
|
|
|
|
|
2010-07-24 23:51:45 +02:00
|
|
|
static int
|
|
|
|
OutputSetattro(PyObject *self, PyObject *nameobj, PyObject *val)
|
2010-07-17 21:19:38 +02:00
|
|
|
{
|
2012-09-21 13:46:06 +02:00
|
|
|
GET_ATTR_STRING(name, nameobj);
|
2010-07-17 21:19:38 +02:00
|
|
|
|
2023-09-21 16:40:12 +02:00
|
|
|
return OutputSetattr(self, name, val);
|
2010-07-17 21:19:38 +02:00
|
|
|
}
|
|
|
|
|
2019-12-04 21:24:53 +01:00
|
|
|
///////////////////////////////////////////////////////
|
|
|
|
// 3. Implementation of the Vim module for Python
|
2010-07-17 21:19:38 +02:00
|
|
|
|
2019-12-04 21:24:53 +01:00
|
|
|
// Window type - Implementation functions
|
|
|
|
// --------------------------------------
|
2010-07-17 21:19:38 +02:00
|
|
|
|
|
|
|
#define WindowType_Check(obj) ((obj)->ob_base.ob_type == &WindowType)
|
|
|
|
|
2019-12-04 21:24:53 +01:00
|
|
|
// Buffer type - Implementation functions
|
|
|
|
// --------------------------------------
|
2010-07-17 21:19:38 +02:00
|
|
|
|
|
|
|
#define BufferType_Check(obj) ((obj)->ob_base.ob_type == &BufferType)
|
|
|
|
|
2011-09-14 15:01:58 +02:00
|
|
|
static PyObject* BufferSubscript(PyObject *self, PyObject *idx);
|
2020-10-21 21:01:59 +02:00
|
|
|
static int BufferAsSubscript(PyObject *self, PyObject *idx, PyObject *val);
|
2010-07-17 21:19:38 +02:00
|
|
|
|
2019-12-04 21:24:53 +01:00
|
|
|
// Line range type - Implementation functions
|
|
|
|
// --------------------------------------
|
2010-07-17 21:19:38 +02:00
|
|
|
|
|
|
|
#define RangeType_Check(obj) ((obj)->ob_base.ob_type == &RangeType)
|
|
|
|
|
2011-09-14 15:01:58 +02:00
|
|
|
static PyObject* RangeSubscript(PyObject *self, PyObject *idx);
|
2020-10-21 21:01:59 +02:00
|
|
|
static int RangeAsItem(PyObject *, Py_ssize_t, PyObject *);
|
|
|
|
static int RangeAsSubscript(PyObject *self, PyObject *idx, PyObject *val);
|
2010-07-17 21:19:38 +02:00
|
|
|
|
2019-12-04 21:24:53 +01:00
|
|
|
// Current objects type - Implementation functions
|
|
|
|
// -----------------------------------------------
|
2010-07-17 21:19:38 +02:00
|
|
|
|
|
|
|
static PySequenceMethods BufferAsSeq = {
|
2019-12-04 21:24:53 +01:00
|
|
|
(lenfunc) BufferLength, // sq_length, len(x)
|
|
|
|
(binaryfunc) 0, // sq_concat, x+y
|
|
|
|
(ssizeargfunc) 0, // sq_repeat, x*n
|
|
|
|
(ssizeargfunc) BufferItem, // sq_item, x[i]
|
|
|
|
0, // was_sq_slice, x[i:j]
|
|
|
|
0, // sq_ass_item, x[i]=v
|
|
|
|
0, // sq_ass_slice, x[i:j]=v
|
|
|
|
0, // sq_contains
|
|
|
|
0, // sq_inplace_concat
|
|
|
|
0, // sq_inplace_repeat
|
2010-07-17 21:19:38 +02:00
|
|
|
};
|
|
|
|
|
2013-04-24 13:39:15 +02:00
|
|
|
static PyMappingMethods BufferAsMapping = {
|
2010-07-17 23:52:29 +02:00
|
|
|
/* mp_length */ (lenfunc)BufferLength,
|
2010-07-17 21:19:38 +02:00
|
|
|
/* mp_subscript */ (binaryfunc)BufferSubscript,
|
2011-06-19 00:27:51 +02:00
|
|
|
/* mp_ass_subscript */ (objobjargproc)BufferAsSubscript,
|
2010-07-17 21:19:38 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
|
2019-12-04 21:24:53 +01:00
|
|
|
// Buffer object
|
2010-07-17 21:19:38 +02:00
|
|
|
|
2010-07-24 23:51:45 +02:00
|
|
|
static PyObject *
|
2013-05-29 22:15:30 +02:00
|
|
|
BufferGetattro(PyObject *self, PyObject *nameobj)
|
2010-07-17 21:19:38 +02:00
|
|
|
{
|
2013-04-24 13:39:15 +02:00
|
|
|
PyObject *r;
|
2010-07-17 21:19:38 +02:00
|
|
|
|
2012-09-21 13:46:06 +02:00
|
|
|
GET_ATTR_STRING(name, nameobj);
|
2010-07-17 21:19:38 +02:00
|
|
|
|
2013-05-29 22:15:30 +02:00
|
|
|
if ((r = BufferAttrValid((BufferObject *)(self), name)))
|
|
|
|
return r;
|
|
|
|
|
2013-04-24 13:39:15 +02:00
|
|
|
if (CheckBuffer((BufferObject *)(self)))
|
2010-07-17 23:52:29 +02:00
|
|
|
return NULL;
|
2010-07-17 21:19:38 +02:00
|
|
|
|
2013-04-24 13:39:15 +02:00
|
|
|
r = BufferAttr((BufferObject *)(self), name);
|
|
|
|
if (r || PyErr_Occurred())
|
|
|
|
return r;
|
2010-07-17 21:19:38 +02:00
|
|
|
else
|
2010-07-17 23:52:29 +02:00
|
|
|
return PyObject_GenericGetAttr(self, nameobj);
|
2010-07-17 21:19:38 +02:00
|
|
|
}
|
|
|
|
|
2013-05-29 22:02:22 +02:00
|
|
|
static int
|
|
|
|
BufferSetattro(PyObject *self, PyObject *nameobj, PyObject *val)
|
|
|
|
{
|
|
|
|
GET_ATTR_STRING(name, nameobj);
|
|
|
|
|
2023-09-21 16:40:12 +02:00
|
|
|
return BufferSetattr(self, name, val);
|
2013-05-29 22:02:22 +02:00
|
|
|
}
|
|
|
|
|
2019-12-04 21:24:53 +01:00
|
|
|
//////////////////
|
2010-07-17 21:19:38 +02:00
|
|
|
|
2010-07-24 23:51:45 +02:00
|
|
|
static PyObject *
|
|
|
|
BufferSubscript(PyObject *self, PyObject* idx)
|
2010-07-17 21:19:38 +02:00
|
|
|
{
|
2012-06-29 12:54:53 +02:00
|
|
|
if (PyLong_Check(idx))
|
|
|
|
{
|
2010-07-17 23:52:29 +02:00
|
|
|
long _idx = PyLong_AsLong(idx);
|
2013-05-21 18:30:34 +02:00
|
|
|
return BufferItem((BufferObject *)(self), _idx);
|
2023-01-22 21:14:53 +00:00
|
|
|
}
|
|
|
|
else if (PySlice_Check(idx))
|
2012-06-29 12:54:53 +02:00
|
|
|
{
|
2010-07-17 23:52:29 +02:00
|
|
|
Py_ssize_t start, stop, step, slicelen;
|
|
|
|
|
2013-05-12 20:36:14 +02:00
|
|
|
if (CheckBuffer((BufferObject *) self))
|
|
|
|
return NULL;
|
|
|
|
|
2014-03-30 16:11:43 +02:00
|
|
|
if (PySlice_GetIndicesEx((PySliceObject_T *)idx,
|
2013-05-12 21:16:23 +02:00
|
|
|
(Py_ssize_t)((BufferObject *)(self))->buf->b_ml.ml_line_count,
|
2010-07-17 23:52:29 +02:00
|
|
|
&start, &stop,
|
2012-06-29 12:54:53 +02:00
|
|
|
&step, &slicelen) < 0)
|
2010-07-17 23:52:29 +02:00
|
|
|
return NULL;
|
2013-05-21 18:30:34 +02:00
|
|
|
return BufferSlice((BufferObject *)(self), start, stop);
|
2012-06-29 12:54:53 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2013-06-23 13:46:40 +02:00
|
|
|
RAISE_INVALID_INDEX_TYPE(idx);
|
2010-07-17 23:52:29 +02:00
|
|
|
return NULL;
|
2010-07-17 21:19:38 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-10-21 21:01:59 +02:00
|
|
|
static int
|
2011-06-19 00:27:51 +02:00
|
|
|
BufferAsSubscript(PyObject *self, PyObject* idx, PyObject* val)
|
|
|
|
{
|
2012-06-29 12:54:53 +02:00
|
|
|
if (PyLong_Check(idx))
|
|
|
|
{
|
2011-06-19 00:27:51 +02:00
|
|
|
long n = PyLong_AsLong(idx);
|
2020-07-06 21:03:06 +02:00
|
|
|
|
|
|
|
if (CheckBuffer((BufferObject *) self))
|
|
|
|
return -1;
|
|
|
|
|
2011-06-19 00:27:51 +02:00
|
|
|
return RBAsItem((BufferObject *)(self), n, val, 1,
|
|
|
|
(Py_ssize_t)((BufferObject *)(self))->buf->b_ml.ml_line_count,
|
|
|
|
NULL);
|
2023-01-22 21:14:53 +00:00
|
|
|
}
|
|
|
|
else if (PySlice_Check(idx))
|
2012-06-29 12:54:53 +02:00
|
|
|
{
|
2011-06-19 00:27:51 +02:00
|
|
|
Py_ssize_t start, stop, step, slicelen;
|
|
|
|
|
2013-05-12 20:36:14 +02:00
|
|
|
if (CheckBuffer((BufferObject *) self))
|
|
|
|
return -1;
|
|
|
|
|
2014-03-30 16:11:43 +02:00
|
|
|
if (PySlice_GetIndicesEx((PySliceObject_T *)idx,
|
2013-05-12 21:16:23 +02:00
|
|
|
(Py_ssize_t)((BufferObject *)(self))->buf->b_ml.ml_line_count,
|
2011-06-19 00:27:51 +02:00
|
|
|
&start, &stop,
|
2012-06-29 12:54:53 +02:00
|
|
|
&step, &slicelen) < 0)
|
2011-06-19 00:27:51 +02:00
|
|
|
return -1;
|
|
|
|
return RBAsSlice((BufferObject *)(self), start, stop, val, 1,
|
|
|
|
(PyInt)((BufferObject *)(self))->buf->b_ml.ml_line_count,
|
|
|
|
NULL);
|
2012-06-29 12:54:53 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2013-06-23 13:46:40 +02:00
|
|
|
RAISE_INVALID_INDEX_TYPE(idx);
|
2011-06-19 00:27:51 +02:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-07-17 21:19:38 +02:00
|
|
|
static PySequenceMethods RangeAsSeq = {
|
2019-12-04 21:24:53 +01:00
|
|
|
(lenfunc) RangeLength, // sq_length, len(x)
|
|
|
|
(binaryfunc) 0, // RangeConcat, sq_concat, x+y
|
|
|
|
(ssizeargfunc) 0, // RangeRepeat, sq_repeat, x*n
|
|
|
|
(ssizeargfunc) RangeItem, // sq_item, x[i]
|
|
|
|
0, // was_sq_slice, x[i:j]
|
|
|
|
(ssizeobjargproc) RangeAsItem, // sq_as_item, x[i]=v
|
|
|
|
0, // sq_ass_slice, x[i:j]=v
|
|
|
|
0, // sq_contains
|
|
|
|
0, // sq_inplace_concat
|
|
|
|
0, // sq_inplace_repeat
|
2010-07-17 21:19:38 +02:00
|
|
|
};
|
|
|
|
|
2013-04-24 13:39:15 +02:00
|
|
|
static PyMappingMethods RangeAsMapping = {
|
2010-07-17 23:52:29 +02:00
|
|
|
/* mp_length */ (lenfunc)RangeLength,
|
2010-07-17 21:19:38 +02:00
|
|
|
/* mp_subscript */ (binaryfunc)RangeSubscript,
|
2011-09-14 15:01:58 +02:00
|
|
|
/* mp_ass_subscript */ (objobjargproc)RangeAsSubscript,
|
2010-07-17 21:19:38 +02:00
|
|
|
};
|
|
|
|
|
2019-12-04 21:24:53 +01:00
|
|
|
// Line range object - Implementation
|
2010-07-17 21:19:38 +02:00
|
|
|
|
2010-07-24 23:51:45 +02:00
|
|
|
static PyObject *
|
|
|
|
RangeGetattro(PyObject *self, PyObject *nameobj)
|
2010-07-17 21:19:38 +02:00
|
|
|
{
|
2012-09-21 13:46:06 +02:00
|
|
|
GET_ATTR_STRING(name, nameobj);
|
2010-07-17 21:19:38 +02:00
|
|
|
|
|
|
|
if (strcmp(name, "start") == 0)
|
2010-07-17 23:52:29 +02:00
|
|
|
return Py_BuildValue("n", ((RangeObject *)(self))->start - 1);
|
2010-07-17 21:19:38 +02:00
|
|
|
else if (strcmp(name, "end") == 0)
|
2010-07-17 23:52:29 +02:00
|
|
|
return Py_BuildValue("n", ((RangeObject *)(self))->end - 1);
|
2010-07-17 21:19:38 +02:00
|
|
|
else
|
2010-07-17 23:52:29 +02:00
|
|
|
return PyObject_GenericGetAttr(self, nameobj);
|
2010-07-17 21:19:38 +02:00
|
|
|
}
|
|
|
|
|
2019-12-04 21:24:53 +01:00
|
|
|
////////////////
|
2010-07-17 21:19:38 +02:00
|
|
|
|
2020-10-21 21:01:59 +02:00
|
|
|
static int
|
2010-07-24 23:51:45 +02:00
|
|
|
RangeAsItem(PyObject *self, Py_ssize_t n, PyObject *val)
|
2010-07-17 21:19:38 +02:00
|
|
|
{
|
|
|
|
return RBAsItem(((RangeObject *)(self))->buf, n, val,
|
2010-07-17 23:52:29 +02:00
|
|
|
((RangeObject *)(self))->start,
|
|
|
|
((RangeObject *)(self))->end,
|
|
|
|
&((RangeObject *)(self))->end);
|
2010-07-17 21:19:38 +02:00
|
|
|
}
|
|
|
|
|
2011-09-14 15:01:58 +02:00
|
|
|
static Py_ssize_t
|
|
|
|
RangeAsSlice(PyObject *self, Py_ssize_t lo, Py_ssize_t hi, PyObject *val)
|
|
|
|
{
|
|
|
|
return RBAsSlice(((RangeObject *)(self))->buf, lo, hi, val,
|
|
|
|
((RangeObject *)(self))->start,
|
|
|
|
((RangeObject *)(self))->end,
|
|
|
|
&((RangeObject *)(self))->end);
|
|
|
|
}
|
|
|
|
|
2010-07-24 23:51:45 +02:00
|
|
|
static PyObject *
|
|
|
|
RangeSubscript(PyObject *self, PyObject* idx)
|
2010-07-17 21:19:38 +02:00
|
|
|
{
|
2012-06-29 12:54:53 +02:00
|
|
|
if (PyLong_Check(idx))
|
|
|
|
{
|
2010-07-17 23:52:29 +02:00
|
|
|
long _idx = PyLong_AsLong(idx);
|
2013-05-21 18:30:34 +02:00
|
|
|
return RangeItem((RangeObject *)(self), _idx);
|
2023-01-22 21:14:53 +00:00
|
|
|
}
|
|
|
|
else if (PySlice_Check(idx))
|
2012-06-29 12:54:53 +02:00
|
|
|
{
|
2010-07-17 23:52:29 +02:00
|
|
|
Py_ssize_t start, stop, step, slicelen;
|
|
|
|
|
2014-03-30 16:11:43 +02:00
|
|
|
if (PySlice_GetIndicesEx((PySliceObject_T *)idx,
|
2010-07-17 23:52:29 +02:00
|
|
|
((RangeObject *)(self))->end-((RangeObject *)(self))->start+1,
|
|
|
|
&start, &stop,
|
2012-06-29 12:54:53 +02:00
|
|
|
&step, &slicelen) < 0)
|
2010-07-17 23:52:29 +02:00
|
|
|
return NULL;
|
2013-05-21 18:30:34 +02:00
|
|
|
return RangeSlice((RangeObject *)(self), start, stop);
|
2012-06-29 12:54:53 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2013-06-23 13:46:40 +02:00
|
|
|
RAISE_INVALID_INDEX_TYPE(idx);
|
2010-07-17 23:52:29 +02:00
|
|
|
return NULL;
|
2010-07-17 21:19:38 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-10-21 21:01:59 +02:00
|
|
|
static int
|
2011-09-14 15:01:58 +02:00
|
|
|
RangeAsSubscript(PyObject *self, PyObject *idx, PyObject *val)
|
|
|
|
{
|
2012-06-29 12:54:53 +02:00
|
|
|
if (PyLong_Check(idx))
|
|
|
|
{
|
2011-09-14 15:01:58 +02:00
|
|
|
long n = PyLong_AsLong(idx);
|
|
|
|
return RangeAsItem(self, n, val);
|
2019-03-30 18:47:01 +01:00
|
|
|
}
|
|
|
|
else if (PySlice_Check(idx))
|
2012-06-29 12:54:53 +02:00
|
|
|
{
|
2011-09-14 15:01:58 +02:00
|
|
|
Py_ssize_t start, stop, step, slicelen;
|
|
|
|
|
2014-03-30 16:11:43 +02:00
|
|
|
if (PySlice_GetIndicesEx((PySliceObject_T *)idx,
|
2011-09-14 15:01:58 +02:00
|
|
|
((RangeObject *)(self))->end-((RangeObject *)(self))->start+1,
|
|
|
|
&start, &stop,
|
2012-06-29 12:54:53 +02:00
|
|
|
&step, &slicelen) < 0)
|
2011-09-14 15:01:58 +02:00
|
|
|
return -1;
|
|
|
|
return RangeAsSlice(self, start, stop, val);
|
2012-06-29 12:54:53 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2013-06-23 13:46:40 +02:00
|
|
|
RAISE_INVALID_INDEX_TYPE(idx);
|
2011-09-14 15:01:58 +02:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-12-04 21:24:53 +01:00
|
|
|
// TabPage object - Implementation
|
2013-05-15 15:12:29 +02:00
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
TabPageGetattro(PyObject *self, PyObject *nameobj)
|
|
|
|
{
|
|
|
|
PyObject *r;
|
|
|
|
|
|
|
|
GET_ATTR_STRING(name, nameobj);
|
|
|
|
|
2013-05-29 22:15:30 +02:00
|
|
|
if ((r = TabPageAttrValid((TabPageObject *)(self), name)))
|
|
|
|
return r;
|
|
|
|
|
2013-05-15 15:12:29 +02:00
|
|
|
if (CheckTabPage((TabPageObject *)(self)))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
r = TabPageAttr((TabPageObject *)(self), name);
|
|
|
|
if (r || PyErr_Occurred())
|
|
|
|
return r;
|
|
|
|
else
|
|
|
|
return PyObject_GenericGetAttr(self, nameobj);
|
|
|
|
}
|
|
|
|
|
2019-12-04 21:24:53 +01:00
|
|
|
// Window object - Implementation
|
2010-07-17 21:19:38 +02:00
|
|
|
|
2010-07-24 23:51:45 +02:00
|
|
|
static PyObject *
|
|
|
|
WindowGetattro(PyObject *self, PyObject *nameobj)
|
2010-07-17 21:19:38 +02:00
|
|
|
{
|
2013-04-24 13:39:15 +02:00
|
|
|
PyObject *r;
|
2010-07-17 21:19:38 +02:00
|
|
|
|
2012-09-21 13:46:06 +02:00
|
|
|
GET_ATTR_STRING(name, nameobj);
|
2010-07-17 21:19:38 +02:00
|
|
|
|
2013-05-29 22:15:30 +02:00
|
|
|
if ((r = WindowAttrValid((WindowObject *)(self), name)))
|
|
|
|
return r;
|
|
|
|
|
2013-04-24 13:39:15 +02:00
|
|
|
if (CheckWindow((WindowObject *)(self)))
|
2010-07-17 23:52:29 +02:00
|
|
|
return NULL;
|
2010-07-17 21:19:38 +02:00
|
|
|
|
2013-04-24 13:39:15 +02:00
|
|
|
r = WindowAttr((WindowObject *)(self), name);
|
|
|
|
if (r || PyErr_Occurred())
|
|
|
|
return r;
|
2010-07-17 21:19:38 +02:00
|
|
|
else
|
2010-07-17 23:52:29 +02:00
|
|
|
return PyObject_GenericGetAttr(self, nameobj);
|
2010-07-17 21:19:38 +02:00
|
|
|
}
|
|
|
|
|
2010-07-24 23:51:45 +02:00
|
|
|
static int
|
|
|
|
WindowSetattro(PyObject *self, PyObject *nameobj, PyObject *val)
|
2010-07-17 21:19:38 +02:00
|
|
|
{
|
2012-09-21 13:46:06 +02:00
|
|
|
GET_ATTR_STRING(name, nameobj);
|
2010-07-17 21:19:38 +02:00
|
|
|
|
2023-09-21 16:40:12 +02:00
|
|
|
return WindowSetattr(self, name, val);
|
2010-07-17 21:19:38 +02:00
|
|
|
}
|
|
|
|
|
2019-12-04 21:24:53 +01:00
|
|
|
// Tab page list object - Definitions
|
2013-05-15 15:12:29 +02:00
|
|
|
|
|
|
|
static PySequenceMethods TabListAsSeq = {
|
2019-12-04 21:24:53 +01:00
|
|
|
(lenfunc) TabListLength, // sq_length, len(x)
|
|
|
|
(binaryfunc) 0, // sq_concat, x+y
|
|
|
|
(ssizeargfunc) 0, // sq_repeat, x*n
|
|
|
|
(ssizeargfunc) TabListItem, // sq_item, x[i]
|
|
|
|
0, // sq_slice, x[i:j]
|
|
|
|
(ssizeobjargproc)0, // sq_as_item, x[i]=v
|
|
|
|
0, // sq_ass_slice, x[i:j]=v
|
|
|
|
0, // sq_contains
|
|
|
|
0, // sq_inplace_concat
|
|
|
|
0, // sq_inplace_repeat
|
2013-05-15 15:12:29 +02:00
|
|
|
};
|
|
|
|
|
2019-12-04 21:24:53 +01:00
|
|
|
// Window list object - Definitions
|
2010-07-17 21:19:38 +02:00
|
|
|
|
|
|
|
static PySequenceMethods WinListAsSeq = {
|
2019-12-04 21:24:53 +01:00
|
|
|
(lenfunc) WinListLength, // sq_length, len(x)
|
|
|
|
(binaryfunc) 0, // sq_concat, x+y
|
|
|
|
(ssizeargfunc) 0, // sq_repeat, x*n
|
|
|
|
(ssizeargfunc) WinListItem, // sq_item, x[i]
|
|
|
|
0, // sq_slice, x[i:j]
|
|
|
|
(ssizeobjargproc)0, // sq_as_item, x[i]=v
|
|
|
|
0, // sq_ass_slice, x[i:j]=v
|
|
|
|
0, // sq_contains
|
|
|
|
0, // sq_inplace_concat
|
|
|
|
0, // sq_inplace_repeat
|
2010-07-17 21:19:38 +02:00
|
|
|
};
|
|
|
|
|
2019-12-04 21:24:53 +01:00
|
|
|
/*
|
|
|
|
* Current items object - Implementation
|
2010-07-17 21:19:38 +02:00
|
|
|
*/
|
2010-07-24 23:51:45 +02:00
|
|
|
static PyObject *
|
2013-04-24 13:39:15 +02:00
|
|
|
CurrentGetattro(PyObject *self, PyObject *nameobj)
|
2010-07-17 21:19:38 +02:00
|
|
|
{
|
2013-05-29 22:36:10 +02:00
|
|
|
PyObject *r;
|
2012-09-21 13:46:06 +02:00
|
|
|
GET_ATTR_STRING(name, nameobj);
|
2013-05-29 22:36:10 +02:00
|
|
|
if (!(r = CurrentGetattr(self, name)))
|
|
|
|
return PyObject_GenericGetAttr(self, nameobj);
|
|
|
|
return r;
|
2010-07-17 21:19:38 +02:00
|
|
|
}
|
|
|
|
|
2010-07-24 23:51:45 +02:00
|
|
|
static int
|
2013-04-24 13:39:15 +02:00
|
|
|
CurrentSetattro(PyObject *self, PyObject *nameobj, PyObject *value)
|
2010-07-17 21:19:38 +02:00
|
|
|
{
|
2013-04-24 13:39:15 +02:00
|
|
|
GET_ATTR_STRING(name, nameobj);
|
|
|
|
return CurrentSetattr(self, name, value);
|
2010-07-17 21:19:38 +02:00
|
|
|
}
|
|
|
|
|
2019-12-04 21:24:53 +01:00
|
|
|
// Dictionary object - Definitions
|
2012-06-29 12:54:53 +02:00
|
|
|
|
2012-09-21 14:00:35 +02:00
|
|
|
static PyObject *
|
|
|
|
DictionaryGetattro(PyObject *self, PyObject *nameobj)
|
|
|
|
{
|
|
|
|
DictionaryObject *this = ((DictionaryObject *) (self));
|
|
|
|
|
|
|
|
GET_ATTR_STRING(name, nameobj);
|
|
|
|
|
|
|
|
if (strcmp(name, "locked") == 0)
|
|
|
|
return PyLong_FromLong(this->dict->dv_lock);
|
|
|
|
else if (strcmp(name, "scope") == 0)
|
|
|
|
return PyLong_FromLong(this->dict->dv_scope);
|
|
|
|
|
|
|
|
return PyObject_GenericGetAttr(self, nameobj);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
DictionarySetattro(PyObject *self, PyObject *nameobj, PyObject *val)
|
|
|
|
{
|
|
|
|
GET_ATTR_STRING(name, nameobj);
|
2023-09-21 16:40:12 +02:00
|
|
|
return DictionarySetattr(self, name, val);
|
2012-06-29 12:54:53 +02:00
|
|
|
}
|
|
|
|
|
2019-12-04 21:24:53 +01:00
|
|
|
// List object - Definitions
|
2012-06-29 12:54:53 +02:00
|
|
|
|
2012-09-21 14:00:35 +02:00
|
|
|
static PyObject *
|
|
|
|
ListGetattro(PyObject *self, PyObject *nameobj)
|
|
|
|
{
|
|
|
|
GET_ATTR_STRING(name, nameobj);
|
|
|
|
|
|
|
|
if (strcmp(name, "locked") == 0)
|
|
|
|
return PyLong_FromLong(((ListObject *) (self))->list->lv_lock);
|
|
|
|
|
|
|
|
return PyObject_GenericGetAttr(self, nameobj);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
ListSetattro(PyObject *self, PyObject *nameobj, PyObject *val)
|
|
|
|
{
|
|
|
|
GET_ATTR_STRING(name, nameobj);
|
2023-09-21 16:40:12 +02:00
|
|
|
return ListSetattr(self, name, val);
|
2012-06-29 12:54:53 +02:00
|
|
|
}
|
|
|
|
|
2019-12-04 21:24:53 +01:00
|
|
|
// Function object - Definitions
|
2012-06-29 12:54:53 +02:00
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
FunctionGetattro(PyObject *self, PyObject *nameobj)
|
|
|
|
{
|
2016-04-14 15:56:09 +02:00
|
|
|
PyObject *r;
|
2012-06-29 12:54:53 +02:00
|
|
|
FunctionObject *this = (FunctionObject *)(self);
|
2012-09-21 13:46:06 +02:00
|
|
|
|
|
|
|
GET_ATTR_STRING(name, nameobj);
|
2012-06-29 12:54:53 +02:00
|
|
|
|
2016-04-14 15:56:09 +02:00
|
|
|
r = FunctionAttr(this, name);
|
|
|
|
if (r || PyErr_Occurred())
|
|
|
|
return r;
|
|
|
|
else
|
|
|
|
return PyObject_GenericGetAttr(self, nameobj);
|
2012-06-29 12:54:53 +02:00
|
|
|
}
|
|
|
|
|
2019-12-04 21:24:53 +01:00
|
|
|
// External interface
|
2010-07-17 21:19:38 +02:00
|
|
|
|
|
|
|
void
|
|
|
|
python3_buffer_free(buf_T *buf)
|
|
|
|
{
|
2023-01-12 12:33:30 +00:00
|
|
|
BufferObject *bp = BUF_PYTHON_REF(buf);
|
|
|
|
if (bp == NULL)
|
|
|
|
return;
|
|
|
|
bp->buf = INVALID_BUFFER_VALUE;
|
|
|
|
BUF_PYTHON_REF(buf) = NULL;
|
2010-07-17 21:19:38 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
python3_window_free(win_T *win)
|
|
|
|
{
|
2023-01-12 12:33:30 +00:00
|
|
|
WindowObject *wp = WIN_PYTHON_REF(win);
|
|
|
|
if (wp == NULL)
|
|
|
|
return;
|
|
|
|
wp->win = INVALID_WINDOW_VALUE;
|
|
|
|
WIN_PYTHON_REF(win) = NULL;
|
2010-07-17 21:19:38 +02:00
|
|
|
}
|
2013-05-15 15:12:29 +02:00
|
|
|
|
|
|
|
void
|
|
|
|
python3_tabpage_free(tabpage_T *tab)
|
|
|
|
{
|
2023-01-12 12:33:30 +00:00
|
|
|
TabPageObject *tp = TAB_PYTHON_REF(tab);
|
|
|
|
if (tp == NULL)
|
|
|
|
return;
|
|
|
|
tp->tab = INVALID_TABPAGE_VALUE;
|
|
|
|
TAB_PYTHON_REF(tab) = NULL;
|
2013-05-15 15:12:29 +02:00
|
|
|
}
|
2010-07-17 21:19:38 +02:00
|
|
|
|
2013-06-10 21:27:29 +02:00
|
|
|
static PyObject *
|
|
|
|
Py3Init_vim(void)
|
|
|
|
{
|
2019-12-04 21:24:53 +01:00
|
|
|
// The special value is removed from sys.path in Python3_Init().
|
2010-07-17 21:19:38 +02:00
|
|
|
static wchar_t *(argv[2]) = {L"/must>not&exist/foo", NULL};
|
|
|
|
|
2013-05-21 19:11:01 +02:00
|
|
|
if (init_types())
|
|
|
|
return NULL;
|
2010-07-17 21:19:38 +02:00
|
|
|
|
2019-12-04 21:24:53 +01:00
|
|
|
// Set sys.argv[] to avoid a crash in warn().
|
2010-07-17 21:19:38 +02:00
|
|
|
PySys_SetArgv(1, argv);
|
|
|
|
|
2013-06-10 21:27:29 +02:00
|
|
|
if ((vim_module = PyModule_Create(&vimmodule)) == NULL)
|
|
|
|
return NULL;
|
|
|
|
|
2013-06-23 16:35:47 +02:00
|
|
|
if (populate_module(vim_module))
|
2011-06-19 00:27:51 +02:00
|
|
|
return NULL;
|
2010-07-17 21:19:38 +02:00
|
|
|
|
2013-06-10 21:27:29 +02:00
|
|
|
if (init_sys_path())
|
2010-07-17 23:52:29 +02:00
|
|
|
return NULL;
|
2010-07-17 21:19:38 +02:00
|
|
|
|
2013-06-10 21:27:29 +02:00
|
|
|
return vim_module;
|
2010-07-17 21:19:38 +02:00
|
|
|
}
|
|
|
|
|
2019-12-04 21:24:53 +01:00
|
|
|
//////////////////////////////////////////////////////////////////////////
|
|
|
|
// 4. Utility functions for handling the interface between Vim and Python.
|
2010-07-17 21:19:38 +02:00
|
|
|
|
2019-12-04 21:24:53 +01:00
|
|
|
/*
|
|
|
|
* Convert a Vim line into a Python string.
|
2010-07-17 21:19:38 +02:00
|
|
|
* All internal newlines are replaced by null characters.
|
|
|
|
*
|
|
|
|
* On errors, the Python exception data is set, and NULL is returned.
|
|
|
|
*/
|
2010-07-24 23:51:45 +02:00
|
|
|
static PyObject *
|
|
|
|
LineToString(const char *str)
|
2010-07-17 21:19:38 +02:00
|
|
|
{
|
|
|
|
PyObject *result;
|
|
|
|
Py_ssize_t len = strlen(str);
|
2020-02-26 13:43:51 +01:00
|
|
|
char *tmp, *p;
|
2010-07-17 21:19:38 +02:00
|
|
|
|
2019-05-28 23:08:19 +02:00
|
|
|
tmp = alloc(len + 1);
|
2010-07-17 21:19:38 +02:00
|
|
|
p = tmp;
|
|
|
|
if (p == NULL)
|
|
|
|
{
|
2010-07-17 23:52:29 +02:00
|
|
|
PyErr_NoMemory();
|
|
|
|
return NULL;
|
2010-07-17 21:19:38 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
while (*str)
|
|
|
|
{
|
2010-07-17 23:52:29 +02:00
|
|
|
if (*str == '\n')
|
|
|
|
*p = '\0';
|
|
|
|
else
|
|
|
|
*p = *str;
|
2010-07-17 21:19:38 +02:00
|
|
|
|
2010-07-17 23:52:29 +02:00
|
|
|
++p;
|
|
|
|
++str;
|
2010-07-17 21:19:38 +02:00
|
|
|
}
|
|
|
|
*p = '\0';
|
|
|
|
|
2020-12-21 16:03:02 +01:00
|
|
|
result = PyUnicode_Decode(tmp, len, (char *)ENC_OPT, ERRORS_DECODE_ARG);
|
2010-07-17 21:19:38 +02:00
|
|
|
|
|
|
|
vim_free(tmp);
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
2012-06-29 12:54:53 +02:00
|
|
|
void
|
2024-11-06 21:50:05 +01:00
|
|
|
do_py3eval(char_u *str, dict_T *locals, typval_T *rettv)
|
2012-06-29 12:54:53 +02:00
|
|
|
{
|
2013-05-21 18:19:38 +02:00
|
|
|
DoPyCommand((char *) str,
|
2024-11-06 21:50:05 +01:00
|
|
|
locals,
|
2023-09-19 20:30:22 +02:00
|
|
|
init_range_eval,
|
2013-05-21 18:19:38 +02:00
|
|
|
(runner) run_eval,
|
|
|
|
(void *) rettv);
|
2019-03-19 22:22:55 +01:00
|
|
|
if (rettv->v_type == VAR_UNKNOWN)
|
2012-06-29 12:54:53 +02:00
|
|
|
{
|
2019-03-19 22:22:55 +01:00
|
|
|
rettv->v_type = VAR_NUMBER;
|
|
|
|
rettv->vval.v_number = 0;
|
2012-06-29 12:54:53 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-02-03 12:55:18 +01:00
|
|
|
int
|
2019-03-19 22:22:55 +01:00
|
|
|
set_ref_in_python3(int copyID)
|
2012-06-29 12:54:53 +02:00
|
|
|
{
|
2015-02-03 13:16:04 +01:00
|
|
|
return set_ref_in_py(copyID);
|
patch 9.0.1776: No support for stable Python 3 ABI
Problem: No support for stable Python 3 ABI
Solution: Support Python 3 stable ABI
Commits:
1) Support Python 3 stable ABI to allow mixed version interoperatbility
Vim currently supports embedding Python for use with plugins, and the
"dynamic" linking option allows the user to specify a locally installed
version of Python by setting `pythonthreedll`. However, one caveat is
that the Python 3 libs are not binary compatible across minor versions,
and mixing versions can potentially be dangerous (e.g. let's say Vim was
linked against the Python 3.10 SDK, but the user sets `pythonthreedll`
to a 3.11 lib). Usually, nothing bad happens, but in theory this could
lead to crashes, memory corruption, and other unpredictable behaviors.
It's also difficult for the user to tell something is wrong because Vim
has no way of reporting what Python 3 version Vim was linked with.
For Vim installed via a package manager, this usually isn't an issue
because all the dependencies would already be figured out. For prebuilt
Vim binaries like MacVim (my motivation for working on this), AppImage,
and Win32 installer this could potentially be an issue as usually a
single binary is distributed. This is more tricky when a new Python
version is released, as there's a chicken-and-egg issue with deciding
what Python version to build against and hard to keep in sync when a new
Python version just drops and we have a mix of users of different Python
versions, and a user just blindly upgrading to a new Python could lead to
bad interactions with Vim.
Python 3 does have a solution for this problem: stable ABI / limited API
(see https://docs.python.org/3/c-api/stable.html). The C SDK limits the
API to a set of functions that are promised to be stable across
versions. This pull request adds an ifdef config that allows us to turn
it on when building Vim. Vim binaries built with this option should be
safe to freely link with any Python 3 libraies without having the
constraint of having to use the same minor version.
Note: Python 2 has no such concept and this doesn't change how Python 2
integration works (not that there is going to be a new version of Python
2 that would cause compatibility issues in the future anyway).
---
Technical details:
======
The stable ABI can be accessed when we compile with the Python 3 limited
API (by defining `Py_LIMITED_API`). The Python 3 code (in `if_python3.c`
and `if_py_both.h`) would now handle this and switch to limited API
mode. Without it set, Vim will still use the full API as before so this
is an opt-in change.
The main difference is that `PyType_Object` is now an opaque struct that
we can't directly create "static types" out of, and we have to create
type objects as "heap types" instead. This is because the struct is not
stable and changes from version to version (e.g. 3.8 added a
`tp_vectorcall` field to it). I had to change all the types to be
allocated on the heap instead with just a pointer to them.
Other functions are also simply missing in limited API, or they are
introduced too late (e.g. `PyUnicode_AsUTF8AndSize` in 3.10) to it that
we need some other ways to do the same thing, so I had to abstract a few
things into macros, and sometimes re-implement functions like
`PyObject_NEW`.
One caveat is that in limited API, `OutputType` (used for replacing
`sys.stdout`) no longer inherits from `PyStdPrinter_Type` which I don't
think has any real issue other than minor differences in how they
convert to a string and missing a couple functions like `mode()` and
`fileno()`.
Also fixed an existing bug where `tp_basicsize` was set incorrectly for
`BufferObject`, `TabListObject, `WinListObject`.
Technically, there could be a small performance drop, there is a little
more indirection with accessing type objects, and some APIs like
`PyUnicode_AsUTF8AndSize` are missing, but in practice I didn't see any
difference, and any well-written Python plugin should try to avoid
excessing callbacks to the `vim` module in Python anyway.
I only tested limited API mode down to Python 3.7, which seemes to
compile and work fine. I haven't tried earlier Python versions.
2) Fix PyIter_Check on older Python vers / type##Ptr unused warning
For PyIter_Check, older versions exposed them as either macros (used in
full API), or a function (for use in limited API). A previous change
exposed PyIter_Check to the dynamic build because Python just moved it
to function-only in 3.10 anyway. Because of that, just make sure we
always grab the function in dynamic builds in earlier versions since
that's what Python eventually did anyway.
3) Move Py_LIMITED_API define to configure script
Can now use --with-python-stable-abi flag to customize what stable ABI
version to target. Can also use an env var to do so as well.
4) Show +python/dyn-stable in :version, and allow has() feature query
Not sure if the "/dyn-stable" suffix would break things, or whether we
should do it another way. Or just don't show it in version and rely on
has() feature checking.
5) Documentation first draft. Still need to implement v:python3_version
6) Fix PyIter_Check build breaks when compiling against Python 3.8
7) Add CI coverage stable ABI on Linux/Windows / make configurable on Windows
This adds configurable options for Windows make files (both MinGW and
MSVC). CI will also now exercise both traditional full API and stable
ABI for Linux and Windows in the matrix for coverage.
Also added a "dynamic" option to Linux matrix as a drive-by change to
make other scripting languages like Ruby / Perl testable under both
static and dynamic builds.
8) Fix inaccuracy in Windows docs
Python's own docs are confusing but you don't actually want to use
`python3.dll` for the dynamic linkage.
9) Add generated autoconf file
10) Add v:python3_version support
This variable indicates the version of Python3 that Vim was built
against (PY_VERSION_HEX), and will be useful to check whether the Python
library you are loading in dynamically actually fits it. When built with
stable ABI, it will be the limited ABI version instead
(`Py_LIMITED_API`), which indicates the minimum version of Python 3 the
user should have, rather than the exact match. When stable ABI is used,
we won't be exposing PY_VERSION_HEX in this var because it just doesn't
seem necessary to do so (the whole point of stable ABI is the promise
that it will work across versions), and I don't want to confuse the user
with too many variables.
Also, cleaned up some documentation, and added help tags.
11) Fix Python 3.7 compat issues
Fix a couple issues when using limited API < 3.8
- Crash on exit: In Python 3.7, if a heap-allocated type is destroyed
before all instances are, it would cause a crash later. This happens
when we destroyed `OptionsType` before calling `Py_Finalize` when
using the limited API. To make it worse, later versions changed the
semantics and now each instance has a strong reference to its own type
and the recommendation has changed to have each instance de-ref its
own type and have its type in GC traversal. To avoid dealing with
these cross-version variations, we just don't free the heap type. They
are static types in non-limited-API anyway and are designed to last
through the entirety of the app, and we also don't restart the Python
runtime and therefore do not need it to have absolutely 0 leaks.
See:
- https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-c-api
- https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api
- PyIter_Check: This function is not provided in limited APIs older than
3.8. Previously I was trying to mock it out using manual
PyType_GetSlot() but it was brittle and also does not actually work
properly for static types (it will generate a Python error). Just
return false. It does mean using limited API < 3.8 is not recommended
as you lose the functionality to handle iterators, but from playing
with plugins I couldn't find it to be an issue.
- Fix loading of PyIter_Check so it will be done when limited API < 3.8.
Otherwise loading a 3.7 Python lib will fail even if limited API was
specified to use it.
12) Make sure to only load `PyUnicode_AsUTF8AndSize` in needed in limited API
We don't use this function unless limited API >= 3.10, but we were
loading it regardless. Usually it's ok in Unix-like systems where Python
just has a single lib that we load from, but in Windows where there is a
separate python3.dll this would not work as the symbol would not have
been exposed in this more limited DLL file. This makes it much clearer
under what condition is this function needed.
closes: #12032
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
2023-08-20 21:18:38 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
int
|
2023-09-24 16:12:07 +02:00
|
|
|
python3_version(void)
|
patch 9.0.1776: No support for stable Python 3 ABI
Problem: No support for stable Python 3 ABI
Solution: Support Python 3 stable ABI
Commits:
1) Support Python 3 stable ABI to allow mixed version interoperatbility
Vim currently supports embedding Python for use with plugins, and the
"dynamic" linking option allows the user to specify a locally installed
version of Python by setting `pythonthreedll`. However, one caveat is
that the Python 3 libs are not binary compatible across minor versions,
and mixing versions can potentially be dangerous (e.g. let's say Vim was
linked against the Python 3.10 SDK, but the user sets `pythonthreedll`
to a 3.11 lib). Usually, nothing bad happens, but in theory this could
lead to crashes, memory corruption, and other unpredictable behaviors.
It's also difficult for the user to tell something is wrong because Vim
has no way of reporting what Python 3 version Vim was linked with.
For Vim installed via a package manager, this usually isn't an issue
because all the dependencies would already be figured out. For prebuilt
Vim binaries like MacVim (my motivation for working on this), AppImage,
and Win32 installer this could potentially be an issue as usually a
single binary is distributed. This is more tricky when a new Python
version is released, as there's a chicken-and-egg issue with deciding
what Python version to build against and hard to keep in sync when a new
Python version just drops and we have a mix of users of different Python
versions, and a user just blindly upgrading to a new Python could lead to
bad interactions with Vim.
Python 3 does have a solution for this problem: stable ABI / limited API
(see https://docs.python.org/3/c-api/stable.html). The C SDK limits the
API to a set of functions that are promised to be stable across
versions. This pull request adds an ifdef config that allows us to turn
it on when building Vim. Vim binaries built with this option should be
safe to freely link with any Python 3 libraies without having the
constraint of having to use the same minor version.
Note: Python 2 has no such concept and this doesn't change how Python 2
integration works (not that there is going to be a new version of Python
2 that would cause compatibility issues in the future anyway).
---
Technical details:
======
The stable ABI can be accessed when we compile with the Python 3 limited
API (by defining `Py_LIMITED_API`). The Python 3 code (in `if_python3.c`
and `if_py_both.h`) would now handle this and switch to limited API
mode. Without it set, Vim will still use the full API as before so this
is an opt-in change.
The main difference is that `PyType_Object` is now an opaque struct that
we can't directly create "static types" out of, and we have to create
type objects as "heap types" instead. This is because the struct is not
stable and changes from version to version (e.g. 3.8 added a
`tp_vectorcall` field to it). I had to change all the types to be
allocated on the heap instead with just a pointer to them.
Other functions are also simply missing in limited API, or they are
introduced too late (e.g. `PyUnicode_AsUTF8AndSize` in 3.10) to it that
we need some other ways to do the same thing, so I had to abstract a few
things into macros, and sometimes re-implement functions like
`PyObject_NEW`.
One caveat is that in limited API, `OutputType` (used for replacing
`sys.stdout`) no longer inherits from `PyStdPrinter_Type` which I don't
think has any real issue other than minor differences in how they
convert to a string and missing a couple functions like `mode()` and
`fileno()`.
Also fixed an existing bug where `tp_basicsize` was set incorrectly for
`BufferObject`, `TabListObject, `WinListObject`.
Technically, there could be a small performance drop, there is a little
more indirection with accessing type objects, and some APIs like
`PyUnicode_AsUTF8AndSize` are missing, but in practice I didn't see any
difference, and any well-written Python plugin should try to avoid
excessing callbacks to the `vim` module in Python anyway.
I only tested limited API mode down to Python 3.7, which seemes to
compile and work fine. I haven't tried earlier Python versions.
2) Fix PyIter_Check on older Python vers / type##Ptr unused warning
For PyIter_Check, older versions exposed them as either macros (used in
full API), or a function (for use in limited API). A previous change
exposed PyIter_Check to the dynamic build because Python just moved it
to function-only in 3.10 anyway. Because of that, just make sure we
always grab the function in dynamic builds in earlier versions since
that's what Python eventually did anyway.
3) Move Py_LIMITED_API define to configure script
Can now use --with-python-stable-abi flag to customize what stable ABI
version to target. Can also use an env var to do so as well.
4) Show +python/dyn-stable in :version, and allow has() feature query
Not sure if the "/dyn-stable" suffix would break things, or whether we
should do it another way. Or just don't show it in version and rely on
has() feature checking.
5) Documentation first draft. Still need to implement v:python3_version
6) Fix PyIter_Check build breaks when compiling against Python 3.8
7) Add CI coverage stable ABI on Linux/Windows / make configurable on Windows
This adds configurable options for Windows make files (both MinGW and
MSVC). CI will also now exercise both traditional full API and stable
ABI for Linux and Windows in the matrix for coverage.
Also added a "dynamic" option to Linux matrix as a drive-by change to
make other scripting languages like Ruby / Perl testable under both
static and dynamic builds.
8) Fix inaccuracy in Windows docs
Python's own docs are confusing but you don't actually want to use
`python3.dll` for the dynamic linkage.
9) Add generated autoconf file
10) Add v:python3_version support
This variable indicates the version of Python3 that Vim was built
against (PY_VERSION_HEX), and will be useful to check whether the Python
library you are loading in dynamically actually fits it. When built with
stable ABI, it will be the limited ABI version instead
(`Py_LIMITED_API`), which indicates the minimum version of Python 3 the
user should have, rather than the exact match. When stable ABI is used,
we won't be exposing PY_VERSION_HEX in this var because it just doesn't
seem necessary to do so (the whole point of stable ABI is the promise
that it will work across versions), and I don't want to confuse the user
with too many variables.
Also, cleaned up some documentation, and added help tags.
11) Fix Python 3.7 compat issues
Fix a couple issues when using limited API < 3.8
- Crash on exit: In Python 3.7, if a heap-allocated type is destroyed
before all instances are, it would cause a crash later. This happens
when we destroyed `OptionsType` before calling `Py_Finalize` when
using the limited API. To make it worse, later versions changed the
semantics and now each instance has a strong reference to its own type
and the recommendation has changed to have each instance de-ref its
own type and have its type in GC traversal. To avoid dealing with
these cross-version variations, we just don't free the heap type. They
are static types in non-limited-API anyway and are designed to last
through the entirety of the app, and we also don't restart the Python
runtime and therefore do not need it to have absolutely 0 leaks.
See:
- https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-c-api
- https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api
- PyIter_Check: This function is not provided in limited APIs older than
3.8. Previously I was trying to mock it out using manual
PyType_GetSlot() but it was brittle and also does not actually work
properly for static types (it will generate a Python error). Just
return false. It does mean using limited API < 3.8 is not recommended
as you lose the functionality to handle iterators, but from playing
with plugins I couldn't find it to be an issue.
- Fix loading of PyIter_Check so it will be done when limited API < 3.8.
Otherwise loading a 3.7 Python lib will fail even if limited API was
specified to use it.
12) Make sure to only load `PyUnicode_AsUTF8AndSize` in needed in limited API
We don't use this function unless limited API >= 3.10, but we were
loading it regardless. Usually it's ok in Unix-like systems where Python
just has a single lib that we load from, but in Windows where there is a
separate python3.dll this would not work as the symbol would not have
been exposed in this more limited DLL file. This makes it much clearer
under what condition is this function needed.
closes: #12032
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
2023-08-20 21:18:38 +02:00
|
|
|
{
|
|
|
|
#ifdef USE_LIMITED_API
|
|
|
|
return Py_LIMITED_API;
|
|
|
|
#else
|
|
|
|
return PY_VERSION_HEX;
|
|
|
|
#endif
|
2012-06-29 12:54:53 +02:00
|
|
|
}
|