Logged In: YES 
user_id=31435

markshep:  As you discovered, closing the report doesn't
stop you from following up.  It just reflects the reality
that I don't consider this to be a Python bug, and am
opposed to trying to worm around it inside Python.

Like many people who have just been burned by a platform
quirk, I think you're over-selling the severity of the
problem while ignoring the costs of worming around it. 
Adding piles of Windows-specific code to what's _currently_
a simple and uniform implementation is an ongoing
maintenance headache, not least because that code will stick
around long after the next version of Windows has removed
the cause for it.  In the meantime it complicates the code
with obscure platform-specific hacks, reducing the
reliability of the code because it also reduces the code's
clarity.  The code can't be sanely tested by Python's
standard test suite either (it apparently requires a Windows
network to provoke, and the test suite assumes no such
thing), and untested hack-code is a horrible idea over time.

While it's true that the docs allow for multiple reads under
the covers, it's talking about cases like file objects
returned by a popen() call or a socket makefile() call when
read() is passed a `size` argument, or when read() is called
with no `size` argument (so it's impossible to know in
advance how large a buffer may be needed to reach EOF).  The
entire reading code for an explicitly-sized read on a
genuine file is a single

    return fread(buf, 1, n, stream);

call today, and on all platforms.

It doesn't look like this can end with reading either:  MS
documents a similar problem with writing, and I expect you
want to see that hacked around too (or, if not, you're
pretty selective ;-)).  Pain spreads.

In return, what's the benefit?  The fact that it _is_ so
hard to find anything via Google about this strongly
suggests to me that trying to read more than 64MB in one
gulp across a vulnerable Windows combo is mighty rare.  If
it happens, the failure isn't silent, an explicit exception
is raised letting the programmer know it didn't work.  While
I appreciate that's irritating, it's not a disaster, and a
programmer who cares can worm around it on their own ("so
don't do that -- read < 64MB per gulp yourself").

Obviously, I'm not going to pursue this.  Since I'm one of
the few people who "does" Windows code for the core, that
does cut the chance that anyone will.  If you want to pursue
it, the best chance is to supply a patch implementing it,
and get someone else to review it.  A stronger case could be
made if, e.g., there was evidence that Perl or PHP or Ruby
or VB or C# or ... intend to worm (or have wormed) around it.