-
Notifications
You must be signed in to change notification settings - Fork 11
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
Multi-phase module initialization #53
Multi-phase module initialization #53
Conversation
Simplify the module initializer in preparation for future work.
Fix a likely leak in 'Message__reduce__' (introduced in PR #51).
Removes direct use of static 'MessageType' in 'Messsage_init'.
Note: currently depends on a static pointer to the type, but that will be removed in the next commit, when we add module state to hold that pointer.
Holds the pointer to the heap-allocated 'Message' type, instead of the static pointer added temporarily in the last commit.
It can't be *used* by the 'Message' type in Python < 3.9 (no way to navigate to the module) but we might find a way around that.
Post-module-creation logic moves to '_zim_module exec' slot.
Preserves the invariant, even though we still cannot navigate to it from methods of static types, which makes the 'is_message' impl still ugly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't say anything about the C code here, I have to trust you that the change is OK. The tests are green, so chances are good that everything's fine...
@davisagli Thanks so much for the close attention to detail! I know this stuff is hard to review, and I really appreciate the remote / async pairing. |
@tseaver I wouldn't count on myself to catch everything that might need to be noticed, but I'm finding it useful for practice reading C code. |
Includes making the
Message
type heap-allocated for Python >= 3.9.I mean to port the mechanism developed here (allowing multi-phase for all Python verisons) to the
zope.interface
branch in zopefoundation/zope.interface#301, which should make it suitable for merging.