This is a bug in the C runtime's handling of "r+" mode with buffering. 

The CRT FILE stream's internal _cnt field, from the POV of the write() call, is the number of bytes that can be written to the internal buffer before it's full. The default buffer size is 4096 bytes. Thus after writing "Some Data", _cnt is at 4096 - 9 == 4087 bytes. 

On the other hand, from the POV of the subsequent read() call, this means there are 4087 bytes in the buffer available to be read. If you change your code to keep the result, you'll see that it is indeed 4087 bytes. 

After the read, _cnt is at 0 and the stream's internal _ptr and _base pointers indicate a full buffer, which gets flushed to disk when the file is closed. If you change your code to print os.path.getsize(testPath) after the file is closed, then you should see that the size is 4096 bytes -- exactly one buffer. 

If you open the file with buffering=512, then this changes to 503 bytes read and creates a 512 byte file.

Can and should Python do anything to work around this problem in the CRT? Or should this issue simply be closed as 3rd party? I'm inclined to close it.