Skip to content

Conversation

@vstinner
Copy link
Contributor

@vstinner vstinner commented Dec 9, 2020

Replace "Py_TYPE(obj)=type;" with "Py_SET_SIZE(obj, type);". The
Py_SET_SIZE() was added to Python 3.9: copy pythoncapi_compat.h
header to src/object/. The file comes from the project:
https://github.com/pythoncapi/pythoncapi_compat

On Python 3.10, Py_SET_SIZE() should now be used rather than using
Py_TYPE() as an l-value:
https://docs.python.org/dev/c-api/structures.html#c.Py_TYPE

Context: https://bugs.python.org/issue39573

Replace "Py_TYPE(obj)=type;" with "Py_SET_SIZE(obj, type);". The
Py_SET_SIZE() was added to Python 3.9: copy pythoncapi_compat.h
header to src/object/. The file comes from the project:
https://github.com/pythoncapi/pythoncapi_compat

On Python 3.10, Py_SET_SIZE() should now be used rather than using
Py_TYPE() as an l-value:
https://docs.python.org/dev/c-api/structures.html#c.Py_TYPE

Context: https://bugs.python.org/issue39573
@vstinner
Copy link
Contributor Author

vstinner commented Dec 9, 2020

See also #329

@stefanseefeld
Copy link
Member

This looks like a duplicate of #328, doesn't it ?

@vstinner
Copy link
Contributor Author

vstinner commented Dec 9, 2020

This looks like a duplicate of #328, doesn't it ?

PR #328 replaces obj->ob_type with Py_TYPE(). It doesn't need pythoncapi_compat.h, since Py_TYPE() exists since Python 2.6.

@stefanseefeld
Copy link
Member

Aren't you referring to #329 instead ?

@vstinner
Copy link
Contributor Author

vstinner commented Dec 9, 2020

This looks like a duplicate of #328, doesn't it ?

Oh wait, ignore my previous comment. I wrote 2 PRs and I didn't notice that you're a talking about a 3rd PR.

Yes, #328 is the same fix, but it doesn't use pythoncapi_compat.h. I propose to use it to avoid having to reimplemented the compatibility layer for old Python versions:

#if PY_VERSION_HEX < 0x030900A4
#  define Py_SET_TYPE(obj, type) ((Py_TYPE(obj) = (type)), (void)0)
#  define Py_SET_SIZE(obj, size) ((Py_SIZE(obj) = (size)), (void)0)
#endif

pythoncapi_compat.h uses static inline functions rather than macros.

@vstinner
Copy link
Contributor Author

vstinner commented Dec 9, 2020

Fedora uses a downstream patch to fix issue: https://src.fedoraproject.org/rpms/boost/blob/master/f/boost-1.73-python3.10.patch Copy of the boost specfile:

# https://bugzilla.redhat.com/show_bug.cgi?id=1896382
# https://github.com/boostorg/python/issues/325
Patch93: boost-1.73-python3.10.patch

@vstinner
Copy link
Contributor Author

vstinner commented Dec 9, 2020

APPVEYOR_BUILD_WORKER_IMAGE=Visual Studio 2019

This job failed because it failed to locate the C++ compiler, whereas the two other AppVeyor jobs passed:

set FARGS=--log=summary --log=output --log=actions --log=commands --with-boost-include=%BOOST_PREFIX% target.arch=%ARCH% cxx.name=msvc cxx.version=%MSVC%
faber %FARGS% config || type config.log
Error: C:\Python36-x64\lib\site-packages\faber\tools\cxx.py:64: no C++ compiler found matching <set cxx.name=msvc cxx.version=16.7.4 target.arch=x86_64>.
faber %FARGS% -j8
Error: C:\Python36-x64\lib\site-packages\faber\tools\cxx.py:64: no C++ compiler found matching <set cxx.name=msvc cxx.version=16.7.4 target.arch=x86_64>.
Command exited with code 1

@stefanseefeld
Copy link
Member

Closed as obsolete.

@vstinner vstinner deleted the py_set_type branch January 4, 2021 10:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants