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

[Tim Peters]

[Guido]
> The locking prevents concurrent threads accessing the stream.
>
> But mixing reads and writes (without intervening fseek etc.) is
> illegal use of the stream, and the C standard allows them to be lax
> here, even if the program was single-threaded.
>
> In other words: the locking is so good that it serializes the
> sequence of reads and writes; but if the sequence of reads and
> writes is illegal, they don't guarantee anything.

We're never going to agree on this one, you know.

My definition of "bug" here has nothing to do with the std:  something's "a
bug" if it's not functioning as designed.  That's all.  So if the
implementers would say "oops!  that should not have happened!", then to me
it's "a bug".  It so happens I believe the MS implementers would consider
this to be a bug under that defn.  Multi-threaded libraries have to be
written to a much higher level than the C std guarantees (been there, done
that, and so have you), and this is specifically corruption in a crucial
area vulnerable to races.  They have a timing hole!  That's clear.  If the
MS implementers don't believe that's "a bug", then I'd say they're too
unprofessional to be allowed in the same country as a multithreaded library
<0.1 wink>.

Your definition of "bug" seems to be more "I don't want it in Python's open
bug list, so I'll do what Tim usually does and appeal to the std in a
transparent effort to convince someone that it's not really 'a bug' -- then
maybe I'll get it off of Python's bug list".

I'm sure you'll agree that's a fair summary of both sides <wink>.

it's-a-bug-and-it's-no-longer-on-python's-open-bug-list-ly y'rs
    - tim