[issue27782] Multi-phase extension module initialization, inconsistent exceptions and conflicts between code and PEP

Xiang Zhang added the comment: Thanks for your notice, Nick. :) Of course I am interested. I'll start following import-sig and reading Petr's good idea. -- ___ Python tracker

[issue27782] Multi-phase extension module initialization, inconsistent exceptions and conflicts between code and PEP

Nick Coghlan added the comment: Xiang, if multi-phase initialisation is an area you're interested in, it occurs to me you may also want to take a look at Petr's proposal to provide efficient access to global module state from methods of extension types:

[issue27782] Multi-phase extension module initialization, inconsistent exceptions and conflicts between code and PEP

Xiang Zhang added the comment: Thanks for your work too, Nick! :) Active reply from the core devs always gives me more motivation to open source. -- ___ Python tracker

[issue27782] Multi-phase extension module initialization, inconsistent exceptions and conflicts between code and PEP

Nick Coghlan added the comment: Thanks for the bug report and the patch! These kinds of collaborative interactions are my favourite aspect of open source participation :) -- resolution: -> fixed stage: commit review -> resolved status: open -> closed

[issue27782] Multi-phase extension module initialization, inconsistent exceptions and conflicts between code and PEP

Roundup Robot added the comment: New changeset 913268337886 by Nick Coghlan in branch '3.5': Issue #27782: Fix m_methods handling in multiphase init https://hg.python.org/cpython/rev/913268337886 New changeset fb509792dffc by Nick Coghlan in branch 'default': Merge #27782 fix from 3.5

[issue27782] Multi-phase extension module initialization, inconsistent exceptions and conflicts between code and PEP

Nick Coghlan added the comment: The patch looks good to me, and the relevant contributor licensing is in place, so I'll be applying this shortly :) -- stage: -> commit review ___ Python tracker

[issue27782] Multi-phase extension module initialization, inconsistent exceptions and conflicts between code and PEP

Changes by Nick Coghlan : -- assignee: -> ncoghlan ___ Python tracker ___ ___

[issue27782] Multi-phase extension module initialization, inconsistent exceptions and conflicts between code and PEP

Xiang Zhang added the comment: Thanks Petr. I'd appreciate it if you are willing to review the patch. Upload a patch to fix this, along with tests and doc updating. But here is something different. In PEP489, it is explicitly stated that "Py_mod_create slot is not responsible for setting

[issue27782] Multi-phase extension module initialization, inconsistent exceptions and conflicts between code and PEP

Petr Viktorin added the comment: Hi! I'm on a tight schedule this week, so I'm not looking into this in detail. But please let me know if you need any help and I'll raise the priority. -- ___ Python tracker

[issue27782] Multi-phase extension module initialization, inconsistent exceptions and conflicts between code and PEP

Xiang Zhang added the comment: Nice point. I'll write a patch to fix this these days. -- ___ Python tracker ___

[issue27782] Multi-phase extension module initialization, inconsistent exceptions and conflicts between code and PEP

Nick Coghlan added the comment: Loosening the constraint on PyModule_GetNameObject would indeed work, but it means the code still has a readability problem: the convention in the C API is that officially ducktyped APIs use the PyObject_* prefix, or one of the other abstract protocols

[issue27782] Multi-phase extension module initialization, inconsistent exceptions and conflicts between code and PEP

Xiang Zhang added the comment: > 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

[issue27782] Multi-phase extension module initialization, inconsistent exceptions and conflicts between code and PEP

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.

[issue27782] Multi-phase extension module initialization, inconsistent exceptions and conflicts between code and PEP

New submission from Xiang Zhang: >From doc [1], when create_module returns a non-module instance, m_methods, >m_traverse, m_clear, m_free must be NULL. But actually in the codes, only >m_traverse, m_clear, m_free are checked and emitting consistent errors. If >m_methods is NULL, it will fail