On 27 August 2013 23:17, Guido van Rossum wrote:
> Thanks for your tiresome work
I'm guessing you meant "tireless" here :-)
Paul
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http:/
2013/8/28 Guido van Rossum :
> Congratulations Victor, PEP 446 is accepted!
Thanks. I just commited the implementation into default (future Python 3.4):
http://hg.python.org/cpython/rev/ef889c3d5dc6
http://bugs.python.org/issue18571
I tested it on Linux, FreeBSD 9, OpenIndiana and Windows 7. Let
Congratulations Victor, PEP 446 is accepted!
Thanks for your tiresome work and the last-minute changes. I will update
the PEP's status to "Accepted" right away. You can change it to "Final"
after all the changes have been committed to the default branch for
inclusion into the next 3.4 alpha.
--
2013/8/27 Antoine Pitrou :
>> On UNIX, the subprocess module closes almost all file descriptors in
>> the child process. This operation requires MAXFD system calls, where
>> MAXFD is the maximum number of file descriptors, even if there are
>> only few open file descriptors. This maximum can be rea
Hi,
I have a small comment to make:
> On UNIX, the subprocess module closes almost all file descriptors in
> the child process. This operation requires MAXFD system calls, where
> MAXFD is the maximum number of file descriptors, even if there are
> only few open file descriptors. This maximum ca
On Mon, 26 Aug 2013 23:45:55 -0400
Scott Dial wrote:
> On 8/26/2013 8:51 AM, Antoine Pitrou wrote:
> > Le Mon, 26 Aug 2013 08:24:58 -0400,
> > Tres Seaver a écrit :
> >> On 08/26/2013 04:36 AM, Antoine Pitrou wrote:
> >>> event-driven processing using network libraries
> >>
> >> Maybe I missed so
Le Tue, 27 Aug 2013 10:37:00 +0200,
Charles-François Natali a écrit :
> 2013/8/27 Antoine Pitrou :
> > Sounds a lot like a network problem, then?
>
> If I'm the only one, it's likely, although these pathological timeouts
> are transient, and I don't have any problem with other servers (my
> line
2013/8/27 Antoine Pitrou :
> Sounds a lot like a network problem, then?
If I'm the only one, it's likely, although these pathological timeouts
are transient, and I don't have any problem with other servers (my
line sustains 8Mb/s without problem).
> Have you tried a traceroute?
I'll try tonight
Le Tue, 27 Aug 2013 08:00:09 +0200,
Charles-François Natali a écrit :
> Hi,
>
> I'm trying to checkout a pristine clone from
> ssh://h...@hg.python.org/cpython, and it's taking forever:
> """
> 07:45:35.605941 IP 192.168.0.23.43098 >
> virt-7yvsjn.psf.osuosl.org.ssh: Flags [.], ack 22081460, win
Simon Cross, 27.08.2013 09:58:
> On Mon, Aug 26, 2013 at 5:57 PM, Antoine Pitrou wrote:
>> What do you mean, "all events have to be ready"?
>> If you look at the unit tests, the events are generated on-the-fly,
>> not at the end of the document.
>> (exactly the same as iterparse(), except that iter
Le Tue, 27 Aug 2013 09:58:57 +0200,
Simon Cross a écrit :
> On Mon, Aug 26, 2013 at 5:57 PM, Antoine Pitrou
> wrote:
> > What do you mean, "all events have to be ready"?
> > If you look at the unit tests, the events are generated on-the-fly,
> > not at the end of the document.
> > (exactly the sa
On Mon, Aug 26, 2013 at 5:57 PM, Antoine Pitrou wrote:
> What do you mean, "all events have to be ready"?
> If you look at the unit tests, the events are generated on-the-fly,
> not at the end of the document.
> (exactly the same as iterparse(), except that iterparse() is blocking)
So you have to
In article
,
Charles-Francois Natali wrote:
> I'm trying to checkout a pristine clone from
> ssh://h...@hg.python.org/cpython, and it's taking forever:
> """
> 07:45:35.605941 IP 192.168.0.23.43098 >
> virt-7yvsjn.psf.osuosl.org.ssh: Flags [.], ack 22081460, win 14225,
> options [nop,nop,TS val
13 matches
Mail list logo
