Lucas P Melo wrote:
Am I understanding this correctly:
* The blocking version would not do any raw reads.
No, the blocking version would keep doing raw reads
until the buffer contains enough bytes.
--
Greg
___
Python-Dev mailing list
Python-Dev@pyth
gl...@divmod.com wrote:
On 07:06 pm, pyt...@rcn.com wrote:
Not sure why we need yet another pep on the subject. Just update PEP
5 if needed.
I agree. The draft covers the same ground. Two PEPs on the same subject
would be redundant where they agree but would create confusion where
they do
On Thu, Jun 18, 2009 at 7:17 PM, Benjamin Peterson wrote:
[snip]
> Backwards Compatibility Rules
> =
>
> This policy applys to all public APIs. These include the C-API, the standard
> library, and the core language including syntax and operation as defined by
> the
> r
On 19 Jun, 09:08 pm, benja...@python.org wrote:
2009/6/19 :
On 02:09 pm, benja...@python.org wrote:
2009/6/19 �:
�What about side-effects, or exceptional conditions? �What about
interactions with subclasses? (Changing a class in a library from
old-style
to new-style has serious re
Fredrik Lundh wrote:
>> I think you really need to get Fredrik Lundh to comment on it. If he
>> can't predict when he'll be able to review the changes, maybe he can
>> accept releasing control of xmlrpclib.
>
> Pointer to the patch?
http://bugs.python.org/issue6267
While I have your attention, p
2009/6/20 "Martin v. Löwis" :
>> I‘d really like to get this stuff in. The performance gains allowing
>> http1.1 and gzip for xmlrpc are quite significant.
>
> I think you really need to get Fredrik Lundh to comment on it. If he
> can't predict when he'll be able to review the changes, maybe he c
> I‘d really like to get this stuff in. The performance gains allowing
> http1.1 and gzip for xmlrpc are quite significant.
I think you really need to get Fredrik Lundh to comment on it. If he
can't predict when he'll be able to review the changes, maybe he can
accept releasing control of xmlrpc
