-
Notifications
You must be signed in to change notification settings - Fork 248
Update for Python 3.11 alpha 6 #294
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
vstinner
commented
Mar 1, 2022
- CFame was renamed to _PyCFrame
- _interpreter_frame was renamed to _PyInterpreterFrame
* CFame was renamed to _PyCFrame * _interpreter_frame was renamed to _PyInterpreterFrame
Python 3.11 alpha6 is not released yet, so I create a draft PR for now. I don't understand how greenlet can be built using _PyCFrame and _PyInterpreterFrame types, with _PyInterpreterFrame being part of the Python internal C API, whereas greenlet doesn't including the Python internal C API. Maybe C++ allows to create pointers to unknown types, but require the types to be defined to deference them. |
Is this ready to be undrafted, @vstinner? |
Right. Ready for review! |
This change is for the master branch. I don't know if gevent and eventlet already use it or are using the 1.x stable branch. Is a separated PR needed? |
I haven't forgotten this. It's just waiting on 3.11a6 being available on GitHub Actions. |
Right now, I only see 3.11a5: https://github.com/actions/python-versions/blob/main/versions-manifest.json |
Please don't merge this yet, as the API changes are not final: https://discuss.python.org/t/proposal-rename-pyinterpreterframe-struct-as-py-framedata/14213/7 |
Don't worry about my previous comment - we'll make sure code that works against 3.11a6 keeps working until faster-cpython/ideas#309 provides a proper public API for the relevant frame manipulation tasks (although feel free to chime in there on the public API that you'd like to see to avoid having to delve into frame object internals) |
It looks like @vstinner, mind updating |
Done. |
@jamadden: GitHub Action jobs are not triggered on this PR? |
Yeah, I saw that. I don't know why, except that the AppVeyor build had been stuck for something like 23 days. I've restarted things and am monitoring. |
Yesterday, GitHub was sick: https://www.githubstatus.com/ Maybe close/reopen my PR if GitHub Actions doesn't start? Or I can create a new PR if needd. |
Closing and re-opening did it. Thanks! |
Thanks for the merge!
Magic! Well, as I wrote, GitHub was sick last days. |
2.0.1 (2022-11-07) ================== - Python 3.11: Fix a memory leak. See `issue 328 <https://github.com/python-greenlet/greenlet/issues/328>`_ and `gevent issue 1924 <https://github.com/gevent/gevent/issues/1924>`_. 2.0.0.post0 (2022-11-03) ======================== - Add ``Programming Language :: Python :: 3.11`` to the PyPI classifier metadata. 2.0.0 (2022-10-31) ================== - Nothing changed yet. 2.0.0rc5 (2022-10-31) ===================== - Linux: Fix another group of rare crashes that could occur when shutting down an interpeter running multiple threads. See `issue 325 <https://github.com/python-greenlet/greenlet/issues/325>`_. 2.0.0rc4 (2022-10-30) ===================== - Linux: Fix a rare crash that could occur when shutting down an interpreter running multiple threads, when some of those threads are in greenlets making calls to functions that release the GIL. 2.0.0rc3 (2022-10-29) ===================== - Python 2: Fix a crash that could occur when raising an old-style instance object. 2.0.0rc2 (2022-10-28) ===================== - Workaround `a CPython 3.8 bug <https://github.com/python/cpython/issues/81308>`_ that could cause the interpreter to crash during an early phase of shutdown with the message "Fatal Python error: Python memory allocator called without holding the GI." This only impacted CPython 3.8a3 through CPython 3.9a5; the fix is only applied to CPython 3.8 releases (please don't use an early alpha release of CPython 3.9). 2.0.0rc1 (2022-10-27) ===================== - Deal gracefully with greenlet switches that occur while deferred deallocation of objects is happening using CPython's "trash can" mechanism. Previously, if a large nested container held items that switched greenlets during delayed deallocation, and that second greenlet also invoked the trash can, CPython's internal state could become corrupt. This was visible as an assertion error in debug builds. Now, the relevant internal state is saved and restored during greenlet switches. See also `gevent issue 1909 <https://github.com/gevent/gevent/issues/1909>`_. - Rename the C API function ``PyGreenlet_GET_PARENT`` to ``PyGreenlet_GetParent`` for consistency. The old name remains available as a deprecated alias. 2.0.0a2 (2022-03-24) ==================== - Fix a crash on older versions of the Windows C runtime when an unhandled C++ exception was thrown inside a greenlet by another native extension. This is a bug in that extension, and the interpreter will still abort, but at least it does so deliberately. Thanks to Kirill Smelkov. See `PR 286 <https://github.com/python-greenlet/greenlet/pull/286>`_. - Musllinux wheels for aarch64 are now built, tested, and uploaded to PyPI. Thanks to Alexander Piskun. - This version of greenlet is known to compile and pass tests on CPython 3.11.0a6. Earlier 3.11 releases will not work; later releases may or may not work. See `PR 294 <https://github.com/python-greenlet/greenlet/pull/294>`_. Special thanks to Victor Stinner, Brandt Bucher and the CPython developers.