I disagree. Running tests in debug code tests more things thanks to
assertions, and provides more info in case of test failure or crash. Some
assertions only fail on some platforms. See for example test_locale which
fails with an assertion error on solaris (since Python 3.3).
Adding one or two sla
"Martin v. L?wis" wrote:
> C: pro: compared to B, build time is reduced (need only
>to build once per branch); disk space is also reduced
>con: it would test a debug build, not a release build
It would be an option to run half of the Unix slaves (especially the ones with
the more aggressi
On Sun, 30 Mar 2014 20:44:02 +0200
"Martin v. Löwis" wrote:
> I have created a buildbot configuration to test freeze. At the moment,
> it has only one builder:
>
> http://buildbot.python.org/all/waterfall?show=AMD64%20Ubuntu%20LTS%20Freeze%203.x
>
> which currently fails as freeze doesn't actual
I have created a buildbot configuration to test freeze. At the moment,
it has only one builder:
http://buildbot.python.org/all/waterfall?show=AMD64%20Ubuntu%20LTS%20Freeze%203.x
which currently fails as freeze doesn't actually work.
The test itself works by first building Python in release mode,
Guido van Rossum :
> Yeah, so the pyftp fix is to keep track of how many timers were
> cancelled, and if the number exceeds a threshold it just recreates the
> heap, something like
>
> heap = [x for x in heap if not x.cancelled]
> heapify(heap)
I measured my target use case with a simple emulatio
I've got a patch with partial tests and documentation that I'm holding off
on upload because I believe there should be a brief discussion.
Long story short, Windows needs a thread to handle writing in a
non-blocking fashion, regardless of the use of asyncio or plain subprocess.
If you'd like to c
