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
-
Jeroen Demeyer -
Nick Coghlan -
Petr Viktorin