[Python-Dev] xreadlines : readlines :: xrange : range

[Tim Peters]

[Guido]
> I don't want to call FLOCKFILE while holding the Python lock, as
> this means that *if* we're blocked in FLOCKFILE (e.g. we're reading
> from a pipe or socket), no other Python thread can run!

Ah, good point!  Doesn't appear an essential point, though:  the
HAVE_GETC_UNLOCKED code could still be fiddled easily enough to call
FLOCKFILE and FUNLOCKFILE exactly once per line, but with the first thread
release before the (dynamically only) FLOCKFILE and the last thread grab
after the (dynamically only) FUNLOCKFILE.  It's just a question of will, but
since that's lacking I'll drop it.

> ...
> I don't think that _filbuf can possibly wait for another thread to
> write data to the same stream object.

OK, I'll buy that.  Dropped too.

> ...
> OK.  It's unique to MS.  So close the bug report with a "won't fix"
> resolution.  There's no point in having bug reports remain open that
> we know we can't fix.

We don't really have a policy about that.  Perhaps you're articulating one
here, though!  I've always left bugs open if they're (a) bugs, and (b) open
<wink>.  For example, I left the Norton Blue-Screen crash bug open (although
I see now you eventually closed that).  Ditto the "Rare hangs in
w9xpopen.exe" bug (which is still open, but will never be fixed by *us*).
Just other examples of things we'll almost certainly never fix ourselves (we
have no handle on them, and all evidence says the OS is screwing up).

My view has been that if a user comes to the bug site, it's most helpful for
them if active (== "still happens") crashes and hangs appear among the open
problems.  Now that your view of it is clearer, I'll switch to yours.

too-easy<wink>-ly y'rs  - tim