homepage

This is a meta-issue to keep track of a global PEP 3121 refactoring effort. Per-module issues will be added as dependencies. Let's move the discussion that is not specific to any particular module here.

Robin,
Perhaps we should start with the "xx" modules: Modules/xxmodule.c and Modules/xxsubtype.c. These modules server as a demonstration of best practices and it is natural to use them to iron out any refactoring issues without any risk to deployed code.

"""
Regarding the suggestion of separating PEP3121 and PEP384. It might be true that datetime and other modules do not benefit directly from PEP 384, however it is still a fact that the stdlib modules should be seen as a set of reference modules, that are all implemented in a way that complies with the implementation fo the xxmodules.
I have talked with Martin von Löwis about this, and as far as I understood him correctly he also sees the PEP384 refactoring applied to the whole stdlib as a necessary "signal" to other developers to refactor their modules accordingly.
""" (Robin Schreiber, #15390, msg177274)
MvL have recently confirmed this on python-dev: "Choice of supporting PEP 384 was deliberate. It will change all types into heap types, which is useful for multiple-interpreter support and GC."
Accordingly, I've changed the title of this issue and added a few PEP 384 only dependencies.

With respect to PEP 384 refactoring, I would like to see Tools/scripts/abitype.py used for most of the conversions. The PEP itself can probably be amended to advertise this tool more prominently.

I have in fact used abitype.py to produce all of my PEP 384 patches, however it failed to work correctly in like 50% of all cases, and I had to complete the rest of the patch by hand.I thought about correcting the abitype.py throughout the GSOC, but I happened to find it easier to simply do the missing steps by hand. (I don't know If the script has been fixed up to this point though).
In any case, it might also be interesting for external extension module developers to make use of a fully working version of this script, so they can make their modules PEP 384 compliant without investing too much time.
One has to keep in mind however that almost any script will fail to work by itself, once we run into problems like refcounting or concurrency when applying the patch to a module.
I will have some free time throughout next week and will start to correct the patches for the xx modules (as Alex proposed), and continue from there to all the other patches I have submitted a year ago.
I am deeply sorry that I have not continued my work on this project earlier, however I dramatically underestimated the amount if work related to university, etc... I still feel obliged to complete all these patches.

I strongly believe that it is worthwhile to invest in fixing abitype.py. It is much easier to review a patch to one python script than to review 50+ patches to C files. There is no excuse for this tool not to work on all stdlib modules. If there are any specific issues with the way individual modules are written that prevent automatic conversion, I would prefer to make a coding style change first and then include all modules in one automated PEP 384 conversion.

The work is now tracked at bpo-1635741.

> The work is now tracked at bpo-1635741.
Which work? bpo-1635741 does not appear to be a meta-issue and in msg381432 it loops back here.