Re: [Python-Dev] PEP 384 final review
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. IMO it could be made PEP384-compliant with two additions that would replace two non-compliant functions: - A new function to create types, since PyStructSequence_InitType is supposed to work on a unititialized static variable: PyTypeObject *PyStructSequence_NewType(PyStructSequence_Desc *desc); - PyStructSequence_SetItem(), similar to the macro PyStructSequence_SET_ITEM; the PyStructSequence structure should be hidden. Sounds good. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 384 final review
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 384 final review
On 29.11.2010 00:40, Martin v. Löwis wrote: I have now completed http://www.python.org/dev/peps/pep-0384/ Benjamin has volunteered to rule on this PEP. Please comment with any changes you want to see, or speak in favor or against this PEP. I looked at a diff with r84330 from the py3k branch. Extensions built with Py_LIMITED_API have the python version encoded in it's name. Which abi name should be used for these extensions? - The m and u modifiers in the abi name are complimentary (?) - debug builds and Py_LIMITED_API are incompatible (?) and therefore the current name should be used? - 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? 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? In favour of the pep. Matthias ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 384 final review
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? Regards ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 384 final review
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/p...@84330 svn://svn.python.org/python/branches/pep-0384 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 384 final review
On Mon, Nov 29, 2010 at 11:37 PM, Matthias Klose d...@ubuntu.com wrote: 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/p...@84330 svn://svn.python.org/python/branches/pep-0384 I had to use the full read/write svn+ssh:python...@svn.python.org repository URLs to get it to give me a diff. 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)), and the bare svn protocol isn't enabled on svn.python.org. Since directory diffs don't appear to be enabled on the svn.python.org ViewVC instance, it would probably be a good idea to put this up on Reitveld so people can more easily see the details of what has been changed on the branch to date. If nobody beats me to it, I'll put one up in the morning. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 384 final review
On Mon, Nov 29, 2010 at 9:40 AM, Martin v. Löwis mar...@v.loewis.de wrote: I have now completed http://www.python.org/dev/peps/pep-0384/ Benjamin has volunteered to rule on this PEP. Please comment with any changes you want to see, or speak in favor or against this PEP. 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). 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. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 384 final review
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___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 384 final review
On Mon, Nov 29, 2010 at 11:24 AM, Matthias Klose d...@ubuntu.com wrote: On 29.11.2010 00:40, Martin v. Löwis wrote: I have now completed http://www.python.org/dev/peps/pep-0384/ Benjamin has volunteered to rule on this PEP. Please comment with any changes you want to see, or speak in favor or against this PEP. I looked at a diff with r84330 from the py3k branch. Extensions built with Py_LIMITED_API have the python version encoded in it's name. Which abi name should be used for these extensions? .. - 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. Once Distutils2 final is released (it's currently in alpha), it will be installable from 2.4 to 3.x and can provide this feature. For Python itself we can backport the feature in its setup.py, until Distutils2 is back to the sdtlib In favour of the pep. +1 Matthias -- Tarek Ziadé | http://ziade.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 384 final review
- 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 384 final review
2010/11/29 Martin v. Löwis mar...@v.loewis.de: - 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. Having an accepted PEP does not imply that it should be implemented in the standard library. For instance PEP 345 and PEP 376 are accepted but implemented in Distutils2. it's also a: - good opportunity to boost Distutils2 adoption - way to get feedback from people for that abi= option and have the chance to correct any design issue before d2 is added in the sdtlib 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. ok. Regards, Martin -- Tarek Ziadé | http://ziade.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 384 final review
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 384 final review
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 BA: make the old names somehow conditional (e.g. put them all into a header file rename3.h, or some such) - release CB: 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 384 final review
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/p...@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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 384 final review
Am 29.11.2010 09:36, schrieb Georg Brandl: 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. Sure, I see no problem with that. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 384 final review
On Tue, Nov 30, 2010 at 12:15 AM, James Y Knight f...@fuhm.net wrote: 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 Ah, thanks, I always forget that part (since it isn't there in the read/write URLs). The SVN output may qualify as one of the least helpful error messages I have ever seen, though :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 384 final review
I have now completed http://www.python.org/dev/peps/pep-0384/ Benjamin has volunteered to rule on this PEP. Please comment with any changes you want to see, or speak in favor or against this PEP. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 384 final review
On 11/28/2010 6:40 PM, Martin v. Löwis wrote: I have now completed http://www.python.org/dev/peps/pep-0384/ The current text contains several error messages like: System Message: WARNING/2 (pep-0384.txt, line 194) Bullet list ends without a blank line; unexpected unindent. Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 384 final review
2010/11/29 Martin v. Löwis mar...@v.loewis.de I have now completed http://www.python.org/dev/peps/pep-0384/ was structseq.h considered? IMO it could be made PEP384-compliant with two additions that would replace two non-compliant functions: - A new function to create types, since PyStructSequence_InitType is supposed to work on a unititialized static variable: PyTypeObject *PyStructSequence_NewType(PyStructSequence_Desc *desc); - PyStructSequence_SetItem(), similar to the macro PyStructSequence_SET_ITEM; the PyStructSequence structure should be hidden. -- Amaury Forgeot d'Arc ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
