Is the intention to only support Python3.8?

The intention is to support at least all Python 3 versions from 3.5 onwards. The Python (3) API and ABI is mostly backwards-compatible for our purposes. The one comment on Python 3.8 just refers to https://docs.python.org/3/whatsnew/3.8.html#debug-build-uses-the-same-abi-as-release-build, which allows us to use the exact same build even for Debug Pythons from 3.8 onwards.

How can a single interop3.cs work across disparate Python 3 releases?

As #995 demonstrated, the Python team continues to change the internals of struct PyObject, with potential impact on Python.NET, so I'm assuming we need to keep version-dependent interop3[n].cs files?

@Jeff17Robbins No, it didn't change. The problem was that they changed the /meaning/ of one of the slots and it now used a different type (same size, though). The structure as such hasn't changed in the Python 3 line, just reusage of deprecated slots and addition of new ones at the end.

@filmor I think it actually did change.

You are correct that the new field Py_ssize_t tp_vectorcall_offset; (represented in interop38.cs as public static int tp_vectorcall_offset = 0;) simply overwrote printfunc tp_print (represented in interop37.cs as public static int tp_print = 0;

But, they also added two new fields right after tp_finalize:

vectorcallfunc tp_vectorcall;

/* bpo-37250: kept for backwards compatibility in CPython 3.8 only */
Py_DEPRECATED(3.8) int (*tp_print)(PyObject *, FILE *, int);

These two new fields change all the offsets of the fields that are defined after them. The structure thus is a different size, and fields we care about, like ht_qualname (aka qualname) has a different offset in Python3.8 as compared to Python3.7.

If you diff interop37.cs withinterop38.cs, you'll see these two new fields:

        public static int tp_vectorcall = 0;
        public static int tp_print = 0;

Meh. Ah well, I'll add this back in due time, but probably in form of a hash-table that is stored in a resource stream instead of autogenerated code. Thanks for the hint :)

Maybe we can create some kind of "sanity check" on the automated process that generates the hash-table to make sure that geninterop.py captured all the fields from the C struct definitions? It is a crucial, yet somewhat fragile, step of the process.

I looked at this branch today and it is currently broken for VS2019.

Even after adding the missing projects to the .sln and fixing the Project SDK

-<Project Sdk="Microsoft.NET.Test.Sdk">
+<Project Sdk="Microsoft.NET.Sdk">

it throws errors about missing properties and methods like

Python.Runtime.Runtime.pyversion
Python.Runtime.Runtime.Machine
Python.Runtime.Runtime.MachineName
Python.Runtime.Runtime.OperatingSystem
Python.Runtime.Runtime.OperatingSystemName
Python.Runtime.Runtime.Py_Initialize()

Am I looking at the incorrect source, or is there anything missing?

@filmor btw, I think this could take advantage of #1043