[Python-3000] Draft PEP for New IO system

[Jim Jewett]

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.

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

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

-jJ