[issue15849] PEP 3121, 384 Refactoring applied to xx module

Change by STINNER Victor : -- resolution: -> duplicate status: open -> closed superseder: -> Py_Finalize() doesn't clear all Python objects at exit ___ Python tracker ___

[issue15849] PEP 3121, 384 Refactoring applied to xx module

STINNER Victor added the comment: > Hum, I reopen the issue: the xx module still defines types statically and so > the "PEP 384" part of this issue is not fixed yet. It's now tracked by bpo-4 "Convert a few stdlib extensions to the limited C API (PEP 384)". --

[issue15849] PEP 3121, 384 Refactoring applied to xx module

STINNER Victor added the comment: See also bpo-40077: "Convert static types to PyType_FromSpec()". -- ___ Python tracker ___ ___

[issue15849] PEP 3121, 384 Refactoring applied to xx module

STINNER Victor added the comment: Hum, I reopen the issue: the xx module still defines types statically and so the "PEP 384" part of this issue is not fixed yet. -- resolution: fixed -> status: closed -> open ___ Python tracker

[issue15849] PEP 3121, 384 Refactoring applied to xx module

STINNER Victor added the comment: Fixed by: commit d5cacbb1d9c3edc02bf0ba01702e7c06da5bc318 Author: Nick Coghlan Date: Sat May 23 22:24:10 2015 +1000 PEP 489: Multi-phase extension module initialization Known limitations of the current implementation: - documentation

[issue15849] PEP 3121, 384 Refactoring applied to xx module

Changes by Stefan Krah stefan-use...@bytereef.org: -- nosy: -skrah ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15849 ___ ___ Python-bugs-list

[issue15849] PEP 3121, 384 Refactoring applied to xx module

Alexander Belopolsky added the comment: I added documentation to the components list because this in the main purpose of this module - to serve as a template for extension module writers. -- assignee: - docs@python components: +Documentation nosy: +docs@python

[issue15849] PEP 3121, 384 Refactoring applied to xx module

Changes by Alexander Belopolsky alexander.belopol...@gmail.com: -- versions: +Python 3.5 -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15849 ___

[issue15849] PEP 3121, 384 Refactoring applied to xx module

Stefan Krah added the comment: I think we should perhaps leave the xxmodule as an example for static types and create another pep-384 version that mentions *potential* performance traps. Of course many modules won't suffer from this, but first-time extension writers tend to paste from the

[issue15849] PEP 3121, 384 Refactoring applied to xx module

Alexander Belopolsky added the comment: create another pep-384 version +1 - and with a more descriptive name than xxmodule.c Suggestions: * pep384module.c * pep384demo.c * pep384.c * abidemo.c -- ___ Python tracker rep...@bugs.python.org

[issue15849] PEP 3121, 384 Refactoring applied to xx module

Robin Schreiber added the comment: Antoine, regarding that the last pending problem with the patch is related to the NULL checking of FindModule, I would be inclined to include your proposed helper API. I see that issue18710 has not been included into the trunk yet, but I think this is mostly

[issue15849] PEP 3121, 384 Refactoring applied to xx module

Robin Schreiber added the comment: Updated patch accordingly. Regarding the problem in http://mail.python.org/pipermail/python-dev/2013-August/127862.html , it can indeed be solved by returning the already existing module object, if PyInit is called multiple times. I followed the discussion

[issue15849] PEP 3121, 384 Refactoring applied to xx module

Antoine Pitrou added the comment: Updated patch accordingly. I don't understand why your patch still has a module state while all objects can be looked up in the module dict. -- ___ Python tracker rep...@bugs.python.org

[issue15849] PEP 3121, 384 Refactoring applied to xx module

Robin Schreiber added the comment: Everything except for the Xxo_Type. But you are right. Then again, why are these global static variables from the start? Isn't this because xxmodule is some kind of dummy module that is supposed to demonstrate some coding conventions on how to build

[issue15849] PEP 3121, 384 Refactoring applied to xx module

Antoine Pitrou added the comment: Everything except for the Xxo_Type. But you are right. Then again, why are these global static variables from the start? Isn't this because xxmodule is some kind of dummy module that is supposed to demonstrate some coding conventions on how to build

[issue15849] PEP 3121, 384 Refactoring applied to xx module

Robin Schreiber added the comment: Updated the patch, corrected multiple syntax errors and missing INCREFS. Also added the comments that include the members names. I am yet undecided regarding the NULL-check for FindModule. Apart from that I have tried to build some tests that prove that

[issue15849] PEP 3121, 384 Refactoring applied to xx module

Antoine Pitrou added the comment: In the example Martin gave in his PEP 3121, the PyInit does not perform any INCREFs on the Variables that are referenced from inside the module state. He therefore left out m_free completely as there was nothing to DECREF within the module state. Back

[issue15849] PEP 3121, 384 Refactoring applied to xx module

Robin Schreiber added the comment: I absolutely agree on mentioning the member names in the comments. :-) In the example Martin gave in his PEP 3121, the PyInit does not perform any INCREFs on the Variables that are referenced from inside the module state. He therefore left out m_free

[issue15849] PEP 3121, 384 Refactoring applied to xx module

Changes by Robin Schreiber robin.schrei...@me.com: -- keywords: +pep3121 -patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15849 ___ ___

[issue15849] PEP 3121, 384 Refactoring applied to xx module

New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the xx module! -- components: Extension Modules files: xxmodule_pep3121-384_v0.patch keywords: patch messages: 169702 nosy: Robin.Schreiber, belopolsky priority: normal severity: normal

[issue15849] PEP 3121, 384 Refactoring applied to xx module

Alexander Belopolsky added the comment: xxmodule.c is used as an example in PEP 3121 itself. To the extent the recipe in the PEP is complete, the changes to actual xxmodule.c should follow the text. For example, the text in PEP recommends to leave m_free member of PyModuleDef 0: static

[issue15849] PEP 3121, 384 Refactoring applied to xx module

Alexander Belopolsky added the comment: +#define xx_state_global + ((xxstate *)PyModule_GetState(PyState_FindModule(xxmodule))) This is unsafe: PyState_FindModule(xxmodule) can return NULL. I think code should account for this possibility and not use this macro. For example,