On 2/11/2011 1:35 PM, Benjamin Peterson wrote:
2011/2/11 Antoine Pitrou:
On Fri, 11 Feb 2011 13:16:12 -0500
Terry Reedy 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 ide
>> 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-id
2011/2/11 Antoine Pitrou :
> On Fri, 11 Feb 2011 13:16:12 -0500
> Terry Reedy 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
On Fri, 11 Feb 2011 13:16:12 -0500
Terry Reedy 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 restric
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
Nick Coghlan wrote:
On Fri, Feb 11, 2011 at 3:25 AM, Mark Shannon 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 mea
On Fri, Feb 11, 2011 at 3:25 AM, Mark Shannon 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
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
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
wrote:
> Doing a search for the regex: "PyAPI_FUNC\([^)]*\) *Py" in .h files,
> which should match API functions (functi
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 pre
>
> 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.
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)
PyErr_Synt
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
PyImport_ExecCodeModuleWithPathnam
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)
> >
Mark Shannon wrote:
> M.-A. Lemburg wrote:
>> Mark Shannon wrote:
>>> Nick Coghlan wrote:
On Thu, Feb 10, 2011 at 8:16 PM, Mark Shannon
wrote:
> Doing a search for the regex: "PyAPI_FUNC\([^)]*\) *Py" in .h files,
> which should match API functions (functions starting _Py are
>>
M.-A. Lemburg wrote:
Mark Shannon wrote:
Nick Coghlan wrote:
On Thu, Feb 10, 2011 at 8:16 PM, Mark Shannon
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 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 yet do
Mark Shannon wrote:
> Nick Coghlan wrote:
>> On Thu, Feb 10, 2011 at 8:16 PM, Mark Shannon
>> 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:
>>>
>>> Vers
Nick Coghlan wrote:
On Thu, Feb 10, 2011 at 8:16 PM, Mark Shannon 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 sure
On Thu, Feb 10, 2011 at 8:16 PM, Mark Shannon 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 743
>
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 suppor
> 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 documenta
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 stab
On Wed, 09 Feb 2011 12:11:43 +
Mark Shannon 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 been there for
On 01:59 pm, ncogh...@gmail.com wrote:
On Wed, Feb 9, 2011 at 11:03 PM, wrote:
On 12:43 pm, ncogh...@gmail.com wrote:
On Wed, Feb 9, 2011 at 10:11 PM, Mark Shannon
wrote:
OK, so UnicodeError_xxx is important for codecs, but surely this
sort of
argument could be made for lots of things.
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 worrying
On 09/02/2011 14:00, Benjamin Peterson wrote:
2011/2/9 Mark Shannon:
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.
Th
2011/2/9 Mark Shannon :
> 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 biggest implementat
On Wed, Feb 9, 2011 at 11:03 PM, wrote:
> On 12:43 pm, ncogh...@gmail.com wrote:
>>
>> On Wed, Feb 9, 2011 at 10:11 PM, Mark Shannon 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 ea
2011/2/9 :
> On 12:43 pm, ncogh...@gmail.com wrote:
>>
>> On Wed, Feb 9, 2011 at 10:11 PM, Mark Shannon 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,
On 12:43 pm, ncogh...@gmail.com wrote:
On Wed, Feb 9, 2011 at 10:11 PM, Mark Shannon
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 t
On Wed, Feb 9, 2011 at 10:11 PM, Mark Shannon 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 forever.
Other implem
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 ca
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 handler
On Wed, 09 Feb 2011 10:37:11 +
Mark Shannon 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 and suc
-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 co
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
http://docs.python.org/py3k/c-api/exceptions.html#except
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-handlin
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 se
40 matches
Mail list logo
