-
Notifications
You must be signed in to change notification settings - Fork 10
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
use C3 MRO if called for via envvar EXTENSIONCLASS_C3_MRO
#34
Conversation
I added testing the C3 variant to |
This is not correct (yet): The GHA configuration is currently ignored by the |
This reverts commit ab320d3.
…on/ExtensionClass into experimental_C3_MRO
Currently without `meta/config` support.
But I added the necessary configuration directly to the GHA config. |
…on/ExtensionClass into experimental_C3_MRO
…on/ExtensionClass into experimental_C3_MRO
The experiment was abandoned in zopefoundation/Zope#982. Keeping the changes here for the record. |
This PR lets the envvar
EXTENSIONCLASS_C3_MRO
control whetherExtensionClass
uses Python's C3 method resolution order or continues to use the old classic one (that from Python's "old style classes"). If defined the value must be an integer and is used as boolean.During the test (using the
Zope
tests) I hit several examples which gave me the impression that the C3 MRO is far less intuitive than the classic one. In easy cases, the problem manifested itself at class definition time (TypeError: cannot determine a consistent resolution error
); however, sometimes, it manifested itself in subtle behavior change. It took me considerable effort to rearrange the class hierarchy in those cases. I expect that other applications, too, would require considerable class hierarchy restructuring to use the C3 MRO.