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
Passing this along from webmaster.
S
---BeginMessage---
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 new entry.
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
On Wed, 09 Feb 2011 21:17:51 +0100
brett.cannon python-check...@python.org 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
On Wed, Feb 9, 2011 at 12:29, Antoine Pitrou solip...@pitrou.net wrote:
On Wed, 09 Feb 2011 21:17:51 +0100
brett.cannon python-check...@python.org 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
-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 about checkout at all?
Le 09/02/2011 23:49, Brett Cannon a écrit :
On Wed, Feb 9, 2011 at 12:29, Antoine Pitrou solip...@pitrou.net 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
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 br...@python.org
date:Wed Feb 09 14:58:17
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
