This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients ncoghlan, petr.viktorin, xiang.zhang
Date 2016-08-17.06:52:38
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1471416758.65.0.873994620411.issue27782@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2016-08-17 06:52:38ncoghlansetrecipients: + ncoghlan, petr.viktorin, xiang.zhang
2016-08-17 06:52:38ncoghlansetmessageid: <1471416758.65.0.873994620411.issue27782@psf.upfronthosting.co.za>
2016-08-17 06:52:38ncoghlanlinkissue27782 messages
2016-08-17 06:52:38ncoghlancreate