Le jeudi 13 octobre 2011 00:44:33, Victor Stinner a écrit :
> Le samedi 8 octobre 2011 16:54:06, Martin v. Löwis a écrit :
> > In benchmarking PEP 393, I noticed that many UTF-8 decode
> > calls originate from C code with static strings, in particular
> > PyObject_CallMethod. Many of such calls alr
Le jeudi 13 octobre 2011 01:27:32, Antoine Pitrou a écrit :
> On Thu, 13 Oct 2011 01:17:29 +0200
>
> victor.stinner wrote:
> > http://hg.python.org/cpython/rev/e5bd48b43a58
> > changeset: 72903:e5bd48b43a58
> > user:Victor Stinner
> > date:Thu Oct 13 00:18:12 2011 +0200
> >
>
Isn't now final?
2011/10/12 antoine.pitrou :
> http://hg.python.org/peps/rev/f50f0e14c774
> changeset: 3962:f50f0e14c774
> parent: 3959:2e1f0462a847
> user: Antoine Pitrou
> date: Thu Oct 13 02:01:21 2011 +0200
> summary:
> Mark PEP accepted.
>
> files:
> pep-3151.txt | 10
On Thu, 13 Oct 2011 01:17:29 +0200
victor.stinner wrote:
> http://hg.python.org/cpython/rev/e5bd48b43a58
> changeset: 72903:e5bd48b43a58
> user:Victor Stinner
> date:Thu Oct 13 00:18:12 2011 +0200
> summary:
> Optimize findchar() for PyUnicode_1BYTE_KIND: use memchr and memrc
Le samedi 8 octobre 2011 16:54:06, Martin v. Löwis a écrit :
> In benchmarking PEP 393, I noticed that many UTF-8 decode
> calls originate from C code with static strings, in particular
> PyObject_CallMethod. Many of such calls already have been optimized
> to cache a string object, however, PyObje
On 10/12/2011 10:58 AM, Barry Warsaw wrote:
On Oct 12, 2011, at 10:24 AM, Benjamin Peterson wrote:
2011/10/12 Antoine Pitrou:
I'd like some advice on what the best path is in cases such as:
A :exc:`socket.error` is raised for errors from the call
to :func:`inet_ntop`.
Should I replace
Le mercredi 12 octobre 2011 21:07:33, charles-francois.natali a écrit :
> changeset: 72897:ee4fe16d9b48
> branch: 2.7
> parent: 69635:f6feed6ec3f9
> user:Charles-François Natali
> date:Wed Oct 12 21:07:54 2011 +0200
> summary:
> Issue #13156: revert changeset f6feed6e
Le 11/10/2011 09:59, Vinay Sajip a écrit :
> To me it does, and it would be useful to have some validation from
> the packaging folks.
I’m trying to catch up, but the wi-fi here is horrible and there are so
many messages! I’ll compose a reply for tomorrow.
Regards
___
Le 12/10/2011 00:22, Barry Warsaw a écrit :
> As the BDFOP for PEP 3151, I hereby accept it for inclusion into Python 3.3.
Congratulations Antoine, and thanks!
Cheers
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listi
On Oct 12, 2011, at 10:24 AM, Benjamin Peterson wrote:
>2011/10/12 Antoine Pitrou :
>> I'd like some advice on what the best path is in cases such as:
>>
>> A :exc:`socket.error` is raised for errors from the call
>> to :func:`inet_ntop`.
>>
>> Should I replace "socket.error" with "OSError" (k
On Wed, Oct 12, 2011 at 09:17, Antoine Pitrou wrote:
>
> Hello,
>
> I'd like some advice on what the best path is in cases such as:
>
> A :exc:`socket.error` is raised for errors from the call
> to :func:`inet_ntop`.
>
> Should I replace "socket.error" with "OSError" (knowing that the
> former
2011/10/12 Antoine Pitrou :
>
> Hello,
>
> I'd like some advice on what the best path is in cases such as:
>
> A :exc:`socket.error` is raised for errors from the call
> to :func:`inet_ntop`.
>
> Should I replace "socket.error" with "OSError" (knowing that the
> former is now an alias of the la
Hello,
I'd like some advice on what the best path is in cases such as:
A :exc:`socket.error` is raised for errors from the call
to :func:`inet_ntop`.
Should I replace "socket.error" with "OSError" (knowing that the
former is now an alias of the latter), or leave "socket.error" so that
peo
2011/10/12 Antoine Pitrou :
> On Tue, 11 Oct 2011 18:22:43 -0400
> Barry Warsaw wrote:
>> As the BDFOP for PEP 3151, I hereby accept it for inclusion into Python 3.3.
>>
>> Congratulations to Antoine for producing a great PEP that has broad
>> acceptance
>> in the Python development community, wi
14 matches
Mail list logo