[Python-3000] Draft PEP for New IO system
steven.bethard at gmail.com
Tue Feb 27 00:00:39 CET 2007
On 2/26/07, Mike Verdone <mike.verdone at gmail.com> wrote:
> Daniel Stutzbach and I have prepared a draft PEP for the new IO system
> for Python 3000.
Thanks for doing this! Generally, it looks pretty good.
> Additionally, it defines a few other methods:
> (should these "is_" functions be attributes instead?
> "file.readable == True")
> Additionally, the abstract base class provides one member variable:
I gather that the reason for methods instead of attributes is that
it's easier to delegate to a method than it is to an attribute? That
is easier to write than::
If that's the motivation, I'd assume that we'd want a ``get_raw()``
method instead of the ``.raw`` attribute. FWLIW, as a user, I'd
rather just work with attributes.
> TextIOBase class implementations additionally provide the following methods:
> Read until newline or EOF and return the line.
> Returns an iterator that returns lines from the file (which
> happens to be 'self').
> Same as readline()
> Same as readlinesiter()
If they do the same thing, why do we want them? I gather that the
next()/readline() duplication is for backwards compatibility, but why
the __iter__()/readlinesiter() duplication?
> Another way to do it is as follows (we should pick one or the other):
> .__init__(self, buffer, encoding=None, newline=None)
> Same as above but if newline is not None use that as the
> newline pattern (for reading and writing), and if newline is not set
> attempt to find the newline pattern from the file and if we can't for
> some reason use the system default newline pattern.
I like this API better, but I'm not certain I understand the proposal.
If I call::
does that mean that any '\r\n' strings in the file will appear as
'\n'? Likewise, if I call::
does that mean that any bare '\n' strings will appear as '\r\n'? If
not, how do I get universal newline support with this API? (FWLIW,
I'd be happy with the you-only-see-newlines-like-you-asked-for-them
> Another implementation, StringIO, creates a file-like TextIO
> implementation without an underlying Buffer I/O object. While similar
> functionality could be provided by wrapping a BytesIO object in a
> Buffered I/O object in a TextIOWrapper, the String I/O object allows
> for much greater efficiency as it does not need to actually performing
> encoding and decoding.
Sorry, I didn't understand this part. The StringIO won't have to do
encoding/decoding when ``.next()`` is called?
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
--- Bucky Katt, Get Fuzzy
More information about the Python-3000