[Python-3000] Draft PEP for New IO system

[Guido van Rossum]

On 2/27/07, Jim Jewett <jimjjewett at gmail.com> wrote:
> On 2/27/07, Guido van Rossum <guido at python.org> wrote:
> > On 2/27/07, Jim Jewett <jimjjewett at gmail.com> wrote:
>
> > > Trying to set (non-)blocking may raise an exception on some streams,
> > > but that still seems better than having to know the internal details
> > > before you can even ask.
>
> > I doubt it -- non-blocking mode is pretty specialized. I want it to be
> > *possible* to use the new I/O library with file descriptors that can
> > return EWOULDBLOCK; I don't necessarily want to make it *easy*.
>
> Rewording to see if I understand:
>
> source.read() will always block, unless something out-of-band has changed it.
>
> *If* it has been changed out-of-band, then None is used to indicate this.

Imprecise language, but I understand what you mean. More exacgt would
be None is returned instead of raising an IOError with errno set to
EWOULDBLOCK (or whatever its equivalent on Windows).

> Therefore, normal code can ignore the possibility, or (to be really
> robust against someone else messing with the input stream) add an "if
> result is None: continue" clause to its loops.

No, since that would mean busy-waiting while the I/O isn't ready,
unless there's a select or similar at the top of the loop, in which
case you're not "normal code". Better raise an exception if you get
this. Better even not to check for this at all if you're not prepared
to handle it -- attempting to use None as a string will raise an
exception for you. You could also treat it as EOF.

> > No it isn't. Calling flush() for writing has no semantics at the
> > highest-level abstraction:
>
> Are you saying that flush() need not be a blocking operation?
> That makes it a bit hard to force interaction.

I didn't intend to say that. Depending on whether and how often you
call flush(), the other side could see your bytes at different times,
but it should see the same data in the same order regardless (except
if you never flush your final writes).

FWIW we just discovered that the buffered writers need a __del__
method that calls flush()...

> >> So saving a text file can cause (whitespace) changes all over?
>
> > It would only normalize line endings, but yeah.
>
> > > That might be OK, but it should at least be called out, so that
> > > editors wanting minimal change will know that they have to implement
> > > their own Text layer.
>
> > I expect them to do that anyway.
>
> I don't.  Wanting to minimize diffs doesn't imply any interest in unicode.
>
> > But I would not be against being able
> > to specify newline="\n" on input and have it mean that \r\n line
> > endings remain in the data where present.
>
> That sort of passthrough mode is enough for me.  Thank you.

OK, I'll update the PEP text.

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