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

Guido van Rossum guido@python.org
Fri, 12 Jan 2001 09:07:30 -0500


> [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!

[Tim]
> 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.

Yes, but if the line is very long, you'd have to use malloc() -- you
can't use _PyString_Resize() since that can access the thread state.
You're right that I don't want to do this.

> > 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).

Yes, as I was thinking about this I realized that that was the policy
I wanted.  So, yes, the w9xpopen popen bug can be closed as WontFix too.

> 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.

I find it more important that the bug list gives us developers an
overview of tasks to be tackled.  The problems that won't go away can
be listed in the Python 2.0 MoinMoin web!

--Guido van Rossum (home page: http://www.python.org/~guido/)