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 tohttps://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 singleinterop3.cs work across disparate Python 3 releases?

As#995 demonstrated, the Python team continues to change the internals ofstruct PyObject, with potential impact on Python.NET, so I'm assuming we need to keep version-dependentinterop3[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 fieldPy_ssize_t tp_vectorcall_offset; (represented ininterop38.cs aspublic static int tp_vectorcall_offset = 0;) simply overwroteprintfunc tp_print (represented ininterop37.cs aspublic static int tp_print = 0;

But, they also added two new fields right aftertp_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 thusis a different size, and fields we care about, likeht_qualname (akaqualname) has a different offset in Python3.8 as compared to Python3.7.

If you diffinterop37.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 thatgeninterop.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.pyversionPython.Runtime.Runtime.MachinePython.Runtime.Runtime.MachineNamePython.Runtime.Runtime.OperatingSystemPython.Runtime.Runtime.OperatingSystemNamePython.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