Expose Py_SIZE, Py_IS_TYPE, Py_SET_SIZE as functions in the Stable ABI

[encukou]

These were available as macros or static inline functions when Py_LIMITED_API was defined, so Stable ABI users were using them anyway. Let's expose them as proper functions so they're easier to change in the future.

Reference implementation: python/cpython#139166

• @encukou
• @erlend-aasland
• @mdboom (abstain)
• @serhiy-storchaka
• @vstinner
• @zooba

[zooba]

I don't love adding a new way for the previous release's Stable ABI to be different from the next one, but under the assumption that free-threading never ships and we don't need an actual breaking change, I see no reason to oppose this change.

We may as well simplify the reference implementation and just make them unconditionally use the new exports, rather than pretending that it's possible to build with 3.15 and have it work on earlier versions. People who need extensions to run/load on earlier releases aren't going to be using these headers anyway.

[vstinner]

Let's expose them as proper functions so they're easier to change in the future.

I understand that the change only affects the limited C API version 3.15 and newer.

I'm fine with that.

[vstinner]

We may as well simplify the reference implementation and just make them unconditionally use the new exports, rather than pretending that it's possible to build with 3.15 and have it work on earlier versions. People who need extensions to run/load on earlier releases aren't going to be using these headers anyway.

While I'm not confident that it works properly, we should try to support building for an old limited C API (ex: 3.14) on recent Python versions (ex: 3.15). It's not a big burden to implement that.

[encukou]

pretending that it's possible to build with 3.15 and have it work on earlier versions

Do you know of any issues around this in the current bugfix branches? We should fix them. (FWIW, it seems that if we switch to PEP 809's abi2026, ever-newer interpreters compiling for 0x03ffyyyy will face the same kind of bugs as 3.15 compiling for 0x030d0000.)

[zooba]

ever-newer interpreters compiling for 0x03ffyyyy will face the same kind of bugs as 3.15 compiling for 0x030d0000

No, because we wouldn't be making this change during 0x03ff2026 - it would be made in 0x03ff2031 at the earliest, which is explicitly incompatible with runtimes that only claim to support abi2026. When user choose to migrate to abi2031, then they're choosing to drop compatibility with abi2026.

Do you know of any issues around this in the current bugfix branches?

Not off the top of my head, though I do see quite a few changes to headers between 3.14 and main, such as optional Py_NewRef calls (based on version) and new alignment specifiers. I expect in most cases it's fine, because we're far more aware of it than before and generally do a good job of getting it right, but it's still a lot of complexity and options. And all it takes is a reference to a 3.15-only function that isn't part of the 3.14 python3.dll to cause the extension to refuse to load.

[encukou]

No, because we wouldn't be making this change during 0x03ff2026 - it would be made in 0x03ff2031 at the earliest

Sure. The issue I'm talking about is that changes/additions in non-limited API can “leak” into an older Limited API, where they don't belong. That could happen by mistake regardless of whether the older Limited API can be 3.3 or 2026.

Anyway, that's a tangent in this issue.

[vstinner]

Ping @erlend-aasland @mdboom @serhiy-storchaka.

[encukou]

Ping @erlend-aasland @serhiy-storchaka

[encukou]

ping @serhiy-storchaka

[encukou]

I don't love adding a new way for the previous release's Stable ABI to be different from the next one, but under the assumption that free-threading never ships and we don't need an actual breaking change, I see no reason to oppose this change.

@zooba, Does that mean you want to oppose this, or make it dependent on some future decision?

[vstinner]

ping @serhiy-storchaka

[encukou]

I don't love adding a new way for the previous release's Stable ABI to be different from the next one, but under the assumption that free-threading never ships and we don't need an actual breaking change, I see no reason to oppose this change.

@zooba, does that mean you want to oppose this, or make it dependent on some future decision?

[encukou]

ping @zooba

[zooba]

Sure, whatever. Just make sure we document somewhere that this doesn't give us any freedom to change the underlying object layouts, since users may still be using the macros to access them.

[vstinner]

Ping @serhiy-storchaka