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? -- http://mail.python.org/mailman/listinfo/python-list
