Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #46225 > unrolled thread

Minor consistency question in io.IOBase

Back to article view | Back to comp.lang.python

Contents

  Minor consistency question in io.IOBase dwight.guth@gmail.com - 2013-05-27 14:22 -0700
    RE: Minor consistency question in io.IOBase Carlos Nepomuceno <carlosnepomuceno@outlook.com> - 2013-05-28 04:59 +0300

#46225 — Minor consistency question in io.IOBase

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 see 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 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 been closed 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?

[toc] | [next] | [standalone]

#46246

----------------------------------------
> Date: Mon, 27 May 2013 14:22:17 -0700
> Subject: Minor consistency question in io.IOBase
> From: dwight.guth@gmail.com
> To: python-list@python.org
>
> 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 see 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 side effect 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 		 	   		  

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web