Message 411996 - Python tracker

➜

This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author	vstinner
Recipients	JunyiXie, KubaO, eric.snow, h-vetinari, mloskot, pablogsal, rhettinger, vstinner
Date	2022-01-28.13:50:38
SpamBayes Score	-1.0
Marked as misclassified	Yes
Message-id	<[email protected]>
In-reply-to

Content
> On such platforms, the `PyGet_Foo` API can be on equal footing with the legacy `Py_Foo` statics, i.e. both would do the same thing. That's how I've done it in my experiment. The obvious problem is that on platforms without compiler support for TLS, `Py_Foo` would be unavailable, and that's probably a no-go for an API that wouldn't be deprecated. My GH-18301 PR uses "#define Py_None Py_GetNone()" which is backward compatible in terms of API. Py_GetNone() can have various implementations, it doesn't matter at the API level.

> On such platforms, the `PyGet_Foo` API can be on equal footing with the legacy `Py_Foo` statics, i.e. both would do the same thing. That's how I've done it in my experiment. The obvious problem is that on platforms without compiler support for TLS, `Py_Foo` would be unavailable, and that's probably a no-go for an API that wouldn't be deprecated.

My GH-18301 PR uses "#define Py_None Py_GetNone()" which is backward compatible in terms of API.

Py_GetNone() can have various implementations, it doesn't matter at the API level.

History
Date	User	Action	Args
2022-01-28 13:50:38	vstinner	set	recipients: + vstinner, rhettinger, eric.snow, mloskot, pablogsal, h-vetinari, JunyiXie, KubaO
2022-01-28 13:50:38	vstinner	set	messageid: <[email protected]>
2022-01-28 13:50:38	vstinner	link	issue39511 messages
2022-01-28 13:50:38	vstinner	create