On Fri, Feb 11, 2011 at 3:25 AM, Mark Shannon <ma...@dcs.gla.ac.uk> wrote: > Antoine Pitrou wrote: >>> >>> Please, don't just document all these. >>> Don't add them to the API, unless they are really needed. >> >> We only add functions when they are actually needed (by us, usually). > > If only you (I presume you mean the CPython devs) need them, > why put them in the API. > That underscore prefix saves a lot of trouble in the long run ;)
Keep in mind that you're asking us to change our audience here. When we modify the C API, we have precisely *three* audiences in mind: 1. CPython developers 2. authors of CPython extensions 3. developers embedding a CPython interpreter (or interpreters) into their application So if we find something that makes life easier for us in group 1, our natural inclination is to make it available to the people in groups 2 and 3 as well, rather than selfishly reserving it for ourselves. We will also take aesthetics and obvious symmetries into account when providing convenience functions (as in the case of PySys_FormatStdout). It's only when we consider something to be an ugly hack, or have some other reason to think we may want to change it in the future, that we opt to make it a private implementation detail. The audience consisting of "authors of other implementations trying to mimic the CPython C API" has never even been on the radar. That's quite a significant philosophical shift, so coming in and asking us to apply it retroactively to a release in its RC phase comes across as being *very* presumptuous. Now that the issue has been brought up, it can certainly be taken into consideration for 3.3. The idea of defining a Py_PORTABLE_API that is even more restrictive than PEP 384 (e.g. eliminating lots of old cruft that is a legacy of CPython's long history of development when it was the *only* viable Python implementation) may also be worth exploring. But no, at this late stage nothing significant is going to be done in the context of 3.2, except perhaps describing the C API changes in more detail in the What's New document (whether or not that happens is up to Raymond - the C API is of very little interest to most Python users, who will either use pre-existing C extensions, or else use something like ctypes, Cython, Pyrex, Boost or SWIG to deal with the details of the C/Python boundary). 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
