Nick Coghlan added the comment:

I think the intended behaviour here is that which was documented in the PEP: 
that m_methods should still work based on ducktyping for reading a __name__ 
attribute and setting the method attributes, even if the result of 
Py_create_mod isn't a module type object.

However, it isn't currently working due to the PyModule_Check call in 
PyModule_GetNameObject, which is in turn called from PyModule_AddFunctions. The 
Py_mod_create docs then reflect that limitation of the implementation.

The cleanest way to refactor and fix this that comes to mind would be to make 
static _get_object_name() and _add_methods_to_object() functions in 
moduleobject.c (which omit any strict type checks), and then call those from 
PyModule_GetNameObject and PyModule_AddFunctions with the explicit typecheck.

That way we don't have to support this for arbitrary third party code calling 
in to the C API, while still allowing it for the specific case of objects 
returned from Py_mod_create.

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27782>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to