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
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
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
-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
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
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
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
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
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
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 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 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 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
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 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 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 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
Passing this along from webmaster.
S
--- Begin Message ---
Not sure who to address this question to. Would you please forward it as
you feel is appropriate?
The python 3.2 release notes say that it compiles against sqlite "2.6".
Does that mean it includes the pysqlite 2.6 module which links
On 2/9/2011 12:32 PM, s...@pobox.com wrote:
Passing this along from webmaster.
It is hard to reply to an attachment rather than inline forwarded
message. However, with rc1
>>> import sqlite3
>>> sqlite3.version
'2.6.0'
>>> sqlite3.sqlite_version
'3.7.4'
I added 'pysqlite' to the "What's ne
> 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 21:17:51 +0100
brett.cannon wrote:
>
>
> -One should always work from a checkout of the CPython source code. While it
> may
> +One should always work from a working copy of the CPython source code.
> +While it may
> be tempting to work from the downloaded copy you already
On Wed, Feb 9, 2011 at 12:29, Antoine Pitrou wrote:
> On Wed, 09 Feb 2011 21:17:51 +0100
> brett.cannon wrote:
>>
>>
>> -One should always work from a checkout of the CPython source code. While it
>> may
>> +One should always work from a working copy of the CPython source code.
>> +While it may
> >
> >> -To get a read-only checkout of CPython's source, you need to checkout the
> >> source
> >> -code. To get a read-only checkout of
> >> +To get a read-only checkout of CPython's source, you need a working copy
> >> the
> >> +source code. To get a read-only checkout of
> >
> > Why talk ab
Le 09/02/2011 23:49, Brett Cannon a écrit :
> On Wed, Feb 9, 2011 at 12:29, Antoine Pitrou wrote:
>>> -To get a read-only checkout of CPython's source, you need to checkout the
>>> source
>>> -code. To get a read-only checkout of
>>> +To get a read-only checkout of CPython's source, you need a wo
Am 09.02.2011 23:58, schrieb brett.cannon:
> brett.cannon pushed 7101df1bd817 to devguide:
>
> http://hg.python.org/devguide/rev/7101df1bd817
> changeset: 291:7101df1bd817
> branch: hg_transition
> tag: tip
> user:Brett Cannon
> date:Wed Feb 09 14:58:17 2011 -0800
>
On 2/9/2011 3:29 PM, Antoine Pitrou wrote:
Why talk about "checkout" at all? It's an SVN/CVS/RCS term, if I'm not
mistaken (even though it may occasionally be used with hg, it's a
synonym of "working copy" there).
I believe it harkens back to early source code control systems where one
person
26 matches
Mail list logo
