Description

There are doctest failures under Python 3 in eclib due to output from eclib being buffered instead of printed.

Python 2 uses the standard C library I/O functions from <stdio.h>. Typically, the C library implements buffering. Now Python 3 bypasses the C library for I/O and does direct system calls from <unistd.h>. The doctest framework always flushes the Python buffers after every test. Under Python 2, this actually flushes the <stdio.h> buffer which is the same buffer used by eclib (and other C/C++ libraries). But on Python 3, this only flushes the Python-specific buffer but not the <stdio.h> buffer.

Oldest firstNewest firstThreaded

Show property changes

Change History (7)

It would be possible to add flushing functions in eclib itself but that does not seem the right approach to me.

I would argue that eclib should actually flush whenever it's "done" producing output. Note that << endl flushes the output, so this is probably a matter of replacing some << "\n" by << endl in eclib, in particular in mw::process(). Alternatively, you could add an explicit cout.flush().

Note that flushing too often can degrade performance. But I guess that I/O performance is not an issue for eclib (you aren't producing megabytes of output per second, right?). So then there is little reason to not use << endl.

It would be possible to add flushing functions in eclib itself but that does not seem the right approach to me.

I would argue that eclib should actually flush whenever it's "done" producing output. Note that << endl flushes the output, so this is probably a matter of replacing some << "\n" by << endl in eclib, in particular in mw::process(). Alternatively, you could add an explicit cout.flush().

Note that flushing too often can degrade performance. But I guess that I/O performance is not an issue for eclib (you aren't producing megabytes of output per second, right?). So then there is little reason to not use << endl.

Certainly I understand all that. The actual programs in eclib do this, but not all the library functions. I can work on that but surely (1) the recent eclib version can be merged without waiting for yet another one, and (2) the flushing of all output in doctests as proposed in this ticket should be done anyway?