Re: [Python-Dev] PEP 573 -- Module State Access from C Extension Methods
On 2018-04-25 20:33, Petr Viktorin wrote:
Perhaps "m_objclass" could point to the module in this case
That was exactly my idea also today. Instead of treating m_objclass as the defining class, we should generalize it to be the "parent" of the function: either the class or the module.
On 04/25/18 14:46, Jeroen Demeyer wrote:
On 2018-04-25 20:33, Petr Viktorin wrote:
Perhaps "m_objclass" could point to the module in this case
That was exactly my idea also today. Instead of treating m_objclass as the defining class, we should generalize it to be the "parent" of the function: either the class or the module.
Great to hear we think alike. However, I think that while reusing the pointer is nice to save space, the two concepts should still be separate, because "defining module" is a reasonable concept even for methods. In particular: - There should be *separate* accessor functions for: - getting the defining class - getting the defining module - The latter would later (in PEP 573) be extended to return the defining module even for class methods (when available) - In Python code, __objclass__ should be the defining class, not the module. - The C field should have a different name (m_parent?), so it isn't that strongly associated with __objclass__. Does that sound reasonable?
On 26 April 2018 at 04:46, Jeroen Demeyer <J.Demeyer@ugent.be> wrote:
On 2018-04-25 20:33, Petr Viktorin wrote:
Perhaps "m_objclass" could point to the module in this case
That was exactly my idea also today. Instead of treating m_objclass as the defining class, we should generalize it to be the "parent" of the function: either the class or the module.
PEP 487 refers to this as the "owner" of a descriptor (See the "__set_name__" example implementation in https://www.python.org/dev/peps/pep-0487/#trait-descriptors ). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (3)
-
Jeroen Demeyer -
Nick Coghlan -
Petr Viktorin