Repository navigation
Conversation
This is planning ahead a bit for when we want to support Limited API + freethreading builds (which I'm strongly assuming is coming in Python 3.15). In this case PyObject will become opaque because it's different between freethreaded and regular builds and so Cython will need to handle most inheritance without including PyObject into the type struct. This PR only covers cyfunction/fusedfunction and not the rest of the shared types, mostly as a proof of concept. I've also not done it outside the Limited API, just because the regular API does the weird "semi-inheritance from PyCFunction" trick. For regular cdef classes there might be some value in giving users individual control.
It got moved when we moved the atomics code out of the memoryview file (because it was being used more widely). However it really is specific to memoryviews so it makes most sense there.
It is inherited which means that we don't need to redefine it for classes that have dict via inheritance. Instead we should allow "this class has a dictoffset" or "one of its first bases has a dictoffset". Factor out some common limited API/type slots code to find the dictoffset of a type. This change is part of the bigger changes to support limited API in Python 3.15(t)+ - in this version the base type won't be the first member of of the object struct, therefore meaning that we can't easily get offsetof the dictoffset. It's taken out because it's standalone so it probably simplifies the review of that change in the future.
They're a little limited in what we can do - we're not able to determine if the C object is too small.
To avoid needing the GIL when doing attribute lookup
Co-authored-by: scoder <[email protected]>
1 of 10 tasks
1 of 2 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of supporting the 3.15 Stable ABI+freethreading.
I've picked these out of my larger cdef class changes because they're handled slightly differently to the others. One thing that I've assumed is that we want to be able to access closure variables quickly (without going through the opaque lookup) so I've just created shadow
cur_scopeandcur_scope_objvariables where thecur_scopevariable points directly to the useful data-structure.