Am 29.11.2010 09:09, schrieb "Martin v. Löwis":

...

I have now completed

http://www.python.org/dev/peps/pep-0384/

was structseq.h considered?

No, it wasn't - unfortunately, it still doesn't get included when including Python.h. I'll add it.

Would 3.2 be a good time to finally include it? All of its macros and declarations are named PyStructSequence*, so there shouldn't be a name clash concern. Georg

...

- Should the distutils support for LIMITED_API be part of the pep, or be implemented later?

In any case, it has to be implemented in Distutils2, not in Distutils. Distutils is frozen and just in maintenance mode.

I think it's too late for that. PEP 3149 is accepted, and it does specify a change to distutils (namely, the abi= parameter). ISTM that an approved PEP will override the distutils code freeze.

For Python itself we can backport the feature in its setup.py, until Distutils2 is back to the sdtlib

This won't be for python itself, but for extension modules. Regards, Martin

Extensions built with Py_LIMITED_API have the python version encoded in it's name. Which abi name should be used for these extensions?

PEP 3149, IIUC, says it should be "abi3". I don't understand what that means, though (with respect to, say, distutils)

- The m and u modifiers in the abi name are complimentary (?)

See above: none of these will be used. Of course, it is possible to name an ABI-conforming extensions with the regular ABI name of the Python release.

- For posix systems the implementation is currently part of the abi name, are Py_LIMITED_API extensions supposed to be compatible with e.g. PyPy?

That's a choice that PyPy needs to make, of course, but Amaury has indicated that they are interested in doing so.

Should the LIMITED_API abi name include the implementation string? - Should the distutils support for LIMITED_API be part of the pep, or be implemented later?

Depends on what support you want. Currently, all you need to do is to define Py_LIMITED_API to the preprocessor - this is something that is already supported in distutils. If you want the support suggested in PEP 3149 (specifying abi=3), it should certainly be implemented in Python 3.2, despite the distutils freeze. Regards, Martin

On 29.11.2010 14:14, Éric Araujo wrote:

Hello,

...

Please comment with any changes you want to see, or speak in favor or against this PEP.

How to get a diff between py3k and this branch?

I used svn diff svn://svn.python.org/python/branches/py3k@84330 svn://svn.python.org/python/branches/pep-0384

On Nov 29, 2010, at 8:58 AM, Nick Coghlan wrote:

The http read only URLs didn't work (no diff returned, just "svn: OPTIONS of 'http://svn.python.org/python/branches/pep-0384': 200 OK (http://svn.python.org)"),

That was the wrong url: you should've used http://svn.python.org/projects/python/branches/pep-0384 James

Am 29.11.2010 14:14, schrieb Éric Araujo:

Hello,

...

Please comment with any changes you want to see, or speak in favor or against this PEP.

How to get a diff between py3k and this branch?

As others have already explained: svn diff http://svn.python.org/projects/python/branches/py3k@84329 http://svn.python.org/projects/python/branches/pep-0384 (84329 is the value of svnmerge-integrated). In any case, I posted it to Rietveld as http://codereview.appspot.com/3262043/ Regards, Martin

This is probably an issue independent of the PEP but there appear to be a *lot* of exposed typedefs for various type slots and other function signatures that don't start with the Py prefix (i.e. getter, setter, unaryfunc and friends).

It's indeed independent: the names don't actually affect the ABI, but the API. Changing them is possible later without risking binary compatibility.

Python.h shouldn't be leaking unprefixed names like that. We certainly shouldn't be enshrining them in the stable ABI without adding prefixes first.

The stable ABI isn't actually enshrining them - what gets enshrined is the value of the typedefs, not their names. I don't mind renaming them, though. I see a number of different cases: - struct names. I don't see a problem to have "typedef struct PyFoo PyFoo" I vaguely recall that there had been compiler problems with that construct at some point, but to my knowledge, they are past, and this is actually both well-formed C and well-formed C++. - function pointer type names - "various" other types For the struct types, in particular for the ones which already have a typedef, I think renaming them should be possible right away. Applications that break should be able to use the typedef instead, and continue to work with older releases. For the function pointer type names, caution is necessary. We cannot remove them, since it would break a lot of code. I also think that some smart naming scheme would be desirable that makes the names all sound right, yet allows easy mapping from the existing types. Once such a scheme is added, we should have a graceful deprecation procedure, such as: - release A: add typedefs in addition to existing pointer types, deprecate pointer types in documentation - release B>A: make the old names somehow conditional (e.g. put them all into a header file rename3.h, or some such) - release C>B: remove rename3.h For the other rest, I think many of them are considered internal (of course, they shouldn't appear in the ABI then at all). Renaming them right away might be fine. Regards, Martin