[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, Paul Moore <p.f.moore at gmail.com> wrote:

> It *may* even be useful if many of these would support non-blocking
> I/O; we're currently considering adding a standard API for returning
> "EWOULDBLOCK" errors (e.g. return None from read() and write()) --
> though we won't be providing an API to turn that on (since it depends
> on the underlying implementation, e.g. sockets vs. files).

I thought the point of the IO subsystem was to abstract away those differences.

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.

> > > The BufferedReader implementation is for sequential-access read-only
> > > objects.  It does not provide a .flush() method, since there is no
> > > sensible circumstance where the user would want to discard the read
> > > buffer.

> > ... typeahead problems.

> ... outside the scope of the PEP; you can do this by
> (somehow) enabling non-blocking mode and then reading until you get
> None.

That does sound like a use case, and flush() is the obvious method.

Are you concerned that having the (rarely needed) method available may
be an attractive nuisance or source of confusion?

> I think for input we should always accept all three line endings so
> you never need to specify anything; for output, we should pick ...

So saving a text file can cause (whitespace) changes all over?

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.

-jJ