Nick Coghlan wrote:
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
On 2/11/2011 4:29 AM, Mark Shannon wrote:
Nick Coghlan wrote:
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
On Fri, 11 Feb 2011 13:16:12 -0500
Terry Reedy tjre...@udel.edu wrote:
On 2/11/2011 4:29 AM, Mark Shannon wrote:
Nick Coghlan wrote:
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
2011/2/11 Antoine Pitrou solip...@pitrou.net:
On Fri, 11 Feb 2011 13:16:12 -0500
Terry Reedy tjre...@udel.edu wrote:
On 2/11/2011 4:29 AM, Mark Shannon wrote:
Nick Coghlan wrote:
Now that the issue has been brought up, it can certainly be taken into
consideration for 3.3. The idea of
1. CPython developers
2. authors of CPython extensions
3. developers embedding a CPython interpreter (or interpreters) into
their application
This makes me wonder who `owns' the API.
Is the CPython developers, the Python community as a whole, the PSF?
(Another one for Python-ideas)
On 2/11/2011 1:35 PM, Benjamin Peterson wrote:
2011/2/11 Antoine Pitrousolip...@pitrou.net:
On Fri, 11 Feb 2011 13:16:12 -0500
Terry Reedytjre...@udel.edu wrote:
On 2/11/2011 4:29 AM, Mark Shannon wrote:
Nick Coghlan wrote:
Now that the issue has been brought up, it can certainly be taken
Thanks to everyone for all their comments so far.
Martin v. Löwis wrote:
The functions may have been add to CPython 8 years ago, but they were
added to the API when they appeared in the docs, between 3.1 and 3.1.3.
How is the API defined, if not by the documentation?
Just to stress and
On Thu, Feb 10, 2011 at 8:16 PM, Mark Shannon ma...@dcs.gla.ac.uk wrote:
Doing a search for the regex: PyAPI_FUNC\([^)]*\) *Py in .h files,
which should match API functions (functions starting _Py are excluded) gives
the following result:
Version matches
3.0 717
3.1.3 728
3.2b2
Mark Shannon, 10.02.2011 11:16:
Of course 743 functions is about 700 too many,
Sorry, but that's so wrong, it's just being mean.
What do you expect from a platform that has grown for more than 20 years?
And which has been the only (real) Python implementation for most of that time.
I'm
Nick Coghlan wrote:
On Thu, Feb 10, 2011 at 8:16 PM, Mark Shannon ma...@dcs.gla.ac.uk wrote:
Doing a search for the regex: PyAPI_FUNC\([^)]*\) *Py in .h files,
which should match API functions (functions starting _Py are excluded) gives
the following result:
Version matches
3.0 717
Mark Shannon wrote:
Nick Coghlan wrote:
On Thu, Feb 10, 2011 at 8:16 PM, Mark Shannon ma...@dcs.gla.ac.uk
wrote:
Doing a search for the regex: PyAPI_FUNC\([^)]*\) *Py in .h files,
which should match API functions (functions starting _Py are
excluded) gives
the following result:
Version
On Thu, Feb 10, 2011 at 11:51 PM, M.-A. Lemburg m...@egenix.com wrote:
The what's new for 3.2 API section:
http://docs.python.org/dev/py3k/whatsnew/3.2.html#build-and-c-api-changes
lists 6 new functions, yet 14 have been added between 3.1.3 and 3.2b2.
Could you identify the ones that are not
M.-A. Lemburg wrote:
Mark Shannon wrote:
Nick Coghlan wrote:
On Thu, Feb 10, 2011 at 8:16 PM, Mark Shannon ma...@dcs.gla.ac.uk
wrote:
Doing a search for the regex: PyAPI_FUNC\([^)]*\) *Py in .h files,
which should match API functions (functions starting _Py are
excluded) gives
the following
Mark Shannon wrote:
M.-A. Lemburg wrote:
Mark Shannon wrote:
Nick Coghlan wrote:
On Thu, Feb 10, 2011 at 8:16 PM, Mark Shannon ma...@dcs.gla.ac.uk
wrote:
Doing a search for the regex: PyAPI_FUNC\([^)]*\) *Py in .h files,
which should match API functions (functions starting _Py are
Le jeudi 10 février 2011 à 16:19 +0100, M.-A. Lemburg a écrit :
And the following were added to 3.2,
of which only 2 are documented:
PyArg_ValidateKeywordArguments
PyAST_CompileEx
Py_CompileString
Py_CompileStringExFlags
PyErr_NewExceptionWithDoc(documented)
snip
And the following were added to 3.2,
of which only 2 are documented:
PyArg_ValidateKeywordArguments
PyAST_CompileEx
Py_CompileString
Py_CompileStringExFlags
PyErr_NewExceptionWithDoc(documented)
PyErr_SyntaxLocationEx
PyErr_WarnFormat
PyFrame_GetLineNumber
Victor Stinner wrote:
Le jeudi 10 février 2011 à 16:19 +0100, M.-A. Lemburg a écrit :
And the following were added to 3.2,
of which only 2 are documented:
PyArg_ValidateKeywordArguments
PyAST_CompileEx
Py_CompileString
Py_CompileStringExFlags
PyErr_NewExceptionWithDoc(documented)
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).
I'm not picking on PySys_FormatStderr, or its author here,
I'm just using it as an example, it seems fairly typical.
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
Am 10.02.2011 15:26, schrieb Mark Shannon:
M.-A. Lemburg wrote:
Mark Shannon wrote:
Nick Coghlan wrote:
On Thu, Feb 10, 2011 at 8:16 PM, Mark Shannon ma...@dcs.gla.ac.uk
wrote:
Doing a search for the regex: PyAPI_FUNC\([^)]*\) *Py in .h files,
which should match API functions (functions
Le jeudi 10 février 2011 à 17:25 +, Mark Shannon a écrit :
What about this one then,
PyFrame_GetLineNumber was added because people were using
PyCode_Addr2Line to get the current line number.
The API will contain then both
PyFrame_GetLineNumber *and* PyCode_Addr2Line.
The API then
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
At sometime between versions 3.1 and the current version, 3.1.3,
the API grew considerably.
See
http://docs.python.org/release/3.1/c-api/exceptions.html#exception-handling
and
http://docs.python.org/py3k/c-api/exceptions.html#exception-handling
The Unicode Exception Objects section is new and
Am 09.02.2011 10:09, schrieb Mark Shannon:
At sometime between versions 3.1 and the current version, 3.1.3,
the API grew considerably.
See
http://docs.python.org/release/3.1/c-api/exceptions.html#exception-handling
and
http://docs.python.org/py3k/c-api/exceptions.html#exception-handling
Georg Brandl wrote:
Am 09.02.2011 10:09, schrieb Mark Shannon:
At sometime between versions 3.1 and the current version, 3.1.3,
the API grew considerably.
See
http://docs.python.org/release/3.1/c-api/exceptions.html#exception-handling
and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
(Not sure if your message went to python-dev too.)
Am 09.02.2011 11:04, schrieb Mark Shannon:
Georg Brandl wrote:
Am 09.02.2011 10:09, schrieb Mark Shannon:
At sometime between versions 3.1 and the current version, 3.1.3,
the API grew
On Wed, 09 Feb 2011 10:37:11 +
Mark Shannon ma...@dcs.gla.ac.uk wrote:
Why redundant?
Because they are all attribute getter and setters. For example:
PyUnicodeDecodeError_GetStart(exc, x) =
PyObject_GetAttr(exc, start, x)
This sort of redundancy seems sensible for list, tuple
Mark Shannon wrote:
The Unicode Exception Objects section is new and seemingly redundant:
http://docs.python.org/py3k/c-api/exceptions.html#unicode-exception-objects
Should this be in the public API?
Those function have been in the public API since we introduced
Unicode callbak error handlers.
M.-A. Lemburg wrote:
Mark Shannon wrote:
The Unicode Exception Objects section is new and seemingly redundant:
http://docs.python.org/py3k/c-api/exceptions.html#unicode-exception-objects
Should this be in the public API?
Those function have been in the public API since we introduced
Unicode
On Wed, Feb 9, 2011 at 10:11 PM, Mark Shannon ma...@dcs.gla.ac.uk wrote:
OK, so UnicodeError_xxx is important for codecs, but surely this sort of
argument could be made for lots of things.
Don't forget that for each function added to the API,
all other implementations have to support it
On 12:43 pm, ncogh...@gmail.com wrote:
On Wed, Feb 9, 2011 at 10:11 PM, Mark Shannon ma...@dcs.gla.ac.uk
wrote:
OK, so UnicodeError_xxx is important for codecs, but surely this sort
of
argument could be made for lots of things.
Don't forget that for each function added to the API,
all other
2011/2/9 exar...@twistedmatrix.com:
On 12:43 pm, ncogh...@gmail.com wrote:
On Wed, Feb 9, 2011 at 10:11 PM, Mark Shannon ma...@dcs.gla.ac.uk wrote:
OK, so UnicodeError_xxx is important for codecs, but surely this sort of
argument could be made for lots of things.
Don't forget that for each
On Wed, Feb 9, 2011 at 11:03 PM, exar...@twistedmatrix.com wrote:
On 12:43 pm, ncogh...@gmail.com wrote:
On Wed, Feb 9, 2011 at 10:11 PM, Mark Shannon ma...@dcs.gla.ac.uk wrote:
OK, so UnicodeError_xxx is important for codecs, but surely this sort of
argument could be made for lots of
2011/2/9 Mark Shannon ma...@dcs.gla.ac.uk:
OK, so UnicodeError_xxx is important for codecs, but surely this sort of
argument could be made for lots of things.
Don't forget that for each function added to the API,
all other implementations have to support it forever.
The C-API is about the
On 09/02/2011 14:00, Benjamin Peterson wrote:
2011/2/9 Mark Shannonma...@dcs.gla.ac.uk:
OK, so UnicodeError_xxx is important for codecs, but surely this sort of
argument could be made for lots of things.
Don't forget that for each function added to the API,
all other implementations have to
On 09/02/2011 13:59, Nick Coghlan wrote:
[snip...]
And, since the C API has never been anywhere near as tightly
controlled as the language definition, alternative implementations are
going to garner more sympathy if they restrict their concerns to the
growth of the stable ABI rather than
On 01:59 pm, ncogh...@gmail.com wrote:
On Wed, Feb 9, 2011 at 11:03 PM, exar...@twistedmatrix.com wrote:
On 12:43 pm, ncogh...@gmail.com wrote:
On Wed, Feb 9, 2011 at 10:11 PM, Mark Shannon ma...@dcs.gla.ac.uk
wrote:
OK, so UnicodeError_xxx is important for codecs, but surely this
sort
On Wed, 09 Feb 2011 12:11:43 +
Mark Shannon ma...@dcs.gla.ac.uk wrote:
Various others have been added:
int Py_EnterRecursiveCall(char *where)
void Py_LeaveRecursiveCall()
int Py_ReprEnter(PyObject *object)
void Py_ReprLeave(PyObject *object)
Again, they haven't been added. They have
On Wed, 09 Feb 2011 14:13:11 -
exar...@twistedmatrix.com wrote:
And, since the C API has never been anywhere near as tightly
controlled as the language definition, alternative implementations are
going to garner more sympathy if they restrict their concerns to the
growth of the stable ABI
The functions may have been add to CPython 8 years ago, but they were
added to the API when they appeared in the docs, between 3.1 and 3.1.3.
How is the API defined, if not by the documentation?
Just to stress and support Georg's explanation: the API is *not* defined
through the
40 matches
Mail list logo
