Minor consistency question in io.IOBase

D

dwight.guth

Hi, so, I don't necessarily know if this is the right place to ask this question since it's kindof a rather technical one which gets into details of the python interpreter itself, but I thought I'd start here and if nobody knew the answer, they could let me know if it makes sense to ask on python-dev.

I am wondering why it is that the default implementations of certain of the"mixin" methods on IOBase seem to behave somewhat inconsistently. Specifically, the behavior of precisely when in the pipeline a method checks to seewhether the object is already closed seems to be inconsistent.

In the following methods:

IOBase.__next__
IOBase.readline
IOBase.tell

In each case, these methods never check to see whether the file is closed. __next__ immediately calls readline(), readline(limit) calls read(1) at most limit times, and tell calls seek(0, 1). It is relying on the underlying method to raise a ValueError if the file is already closed. Otherwise, __next__ and readline will raise AttributeErrors on unreadable files, and tell will raise an UnsupportedOperation on unseekable files. A side effect of this is that readline(0) on a closed file will succeed.

In the following methods, however:

IOBase.writelines
IOBase.readlines

In each case, the methods will check to determine whether the file has beenclosed before ever calling their underlying method. Thus, calling writelines([]) will raise a ValueError on a closed file, though it never calls write. Similarly, readlines() will raise a ValueError on a closed file before ever calling readline() even once.

Can someone explain to me if there's some kind of consistent logic that explains the differing behaviors of these functions? Or is it simply an oversight on the part of the people who wrote Modules/_io/iobase.c?
 
C

Carlos Nepomuceno

----------------------------------------
Date: Mon, 27 May 2013 14:22:17 -0700
Subject: Minor consistency question in io.IOBase
From: (e-mail address removed)
To: (e-mail address removed)

Hi, so, I don't necessarily know if this is the right place to ask this question since it's kindof a rather technical one which gets into details of the python interpreter itself, but I thought I'd start here and if nobody knew the answer, they could let me know if it makes sense to ask onpython-dev.

I am wondering why it is that the default implementations of certain of the "mixin" methods on IOBase seem to behave somewhat inconsistently. Specifically, the behavior of precisely when in the pipeline a method checks tosee whether the object is already closed seems to be inconsistent.

In the following methods:

IOBase.__next__
IOBase.readline
IOBase.tell

In each case, these methods never check to see whether the file is closed. __next__ immediately calls readline(), readline(limit) calls read(1) at most limit times, and tell calls seek(0, 1). It is relying on the underlying method to raise a ValueError if the file is already closed. Otherwise, __next__ and readline will raise AttributeErrors on unreadable files, and tell will raise an UnsupportedOperation on unseekable files. A sideeffect of this is that readline(0) on a closed file will succeed.

According to [1] & [2] it's a bug! Report the issue: http://bugs.python.org/

"close()
Flush and close this stream. This method has no effect if the file is already closed. Once the file is closed, any operation on the file (e.g. reading or writing) will raise a ValueError."

[1] http://docs.python.org/2/library/io.html#i-o-base-classes
[2] http://docs.python.org/3.3/library/io.html#i-o-base-classes
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,733
Messages
2,569,440
Members
44,832
Latest member
GlennSmall

Latest Threads

Top