Title: file.fileno and file.isatty() should be implementable by any file like object
Type: enhancement Stage:
Components: Documentation Versions: Python 3.0
Status: closed Resolution: works for me
Dependencies: Superseder:
Assigned To: fdrake Nosy List: fdrake, jafo, nirs, pythonmeister
Priority: low Keywords:

Created on 2007-09-07 02:00 by nirs, last changed 2007-09-17 18:37 by jafo. This issue is now closed.

Messages (5)
msg55724 - (view) Author: Nir Soffer (nirs) * Date: 2007-09-07 02:00
The docs (
types-str-bytes-list-tuple-buffer-range) warn that .fileno and .istty 
should not be implemented by a file like object.

This require client to check if the file object has the attribute before 
they call the method, instead of treating all files the same.

    if hasattr(foo, 'istty'):
        if foo.istty():
            # ...

Instead of:

    if foo.istty():
        # ...

istty can easily return False. fileno can return invalid file descriptor 
number (-1?).
msg55743 - (view) Author: Stefan Sonnenberg-Carstens (pythonmeister) Date: 2007-09-07 20:19
You are free to do what you want.
Reasons for not implementing fileno and isatty are:
- fileno should be an integer pointing to a real file,
so that low-level functions in libc can handle that. Can you provide
such ? (see
- duck-typing / there must be a difference to "real" files in the first
msg55955 - (view) Author: Sean Reifschneider (jafo) * (Python committer) Date: 2007-09-17 09:05
This is a documentation complaint, right?  Perhaps more of a discussion
of why not implement these attributes on file-like objects.  In general,
I believe the documentation is correct.  Setting fileno to -1 is likely
to break other things in unexpected ways.  Because when opening a real
file object, -1 would mean the file open failed, and the file object
would not get created.

The documentation is right, right?
msg55963 - (view) Author: Fred Drake (fdrake) (Python committer) Date: 2007-09-17 11:34
The documentation does not say what's implied by msg55724; they methods
can (and arguably should) be implmented by types for which they apply
(for which there is a corresponding file descriptor, for example).

There is an API issue here as well: what about a wrapper type that is
sometimes associated with a real file, and sometimes not?  I suppose in
that case the factory (constructor) needs to detect the situation and
return an instance of an appropriate type.

The documentation is clear, so far as it goes, but is arguably incomplete.
msg55974 - (view) Author: Sean Reifschneider (jafo) * (Python committer) Date: 2007-09-17 18:37
I'm thinking that nirs is not thinking of this in the "duck typing"
environment.  Duck typing says that you implement things that are
appropriate for your object type, and code does what it needs to do.  If
the object doesn't support attributes that the code it's passed to
needs, (it doesn't "quack like a duck"), then the code should fail.

I think nirs is thinking that you have to check every attribute before
you use it.  But if the object you implement doesn't reasonably have a
"istty" or "fileno" associated with it, the Python Way is that if you
pass it to code that needs that attribute, that it bomb out.

There may be cases where you might write code that checks for an
attribute, say if the code can provide enhanced functionality if the
attribute is available, but can still provide it's basic functionality
if it does not.

I'm agreeing that I don't think the documentation is incorrect in this case.

I'm thinking that nirs should probably take this to the python mailing
list, and if after discussion there it is believed to still be a
problem, reference the thread here and re-open it.  I'm going to call it
closed for the moment.
Date User Action Args
2007-09-17 18:37:50jafosetstatus: open -> closed
resolution: works for me
messages: + msg55974
2007-09-17 11:34:24fdrakesetmessages: + msg55963
2007-09-17 09:05:10jafosetpriority: low
assignee: fdrake
messages: + msg55955
components: + Documentation, - Library (Lib)
nosy: + fdrake, jafo
2007-09-07 20:19:43pythonmeistersetnosy: + pythonmeister
messages: + msg55743
2007-09-07 02:00:04nirscreate