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
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
>
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
> >
> >> -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
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
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
> 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 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
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 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
26 matches
Mail list logo
