The docs (http://docs.python.org/dev/3.0/library/stdtypes.html#sequence-
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?).

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 http://netbsd.gw.com/cgi-bin/man-cgi?open++NetBSD-current)
- duck-typing / there must be a difference to "real" files in the first
sense

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?

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.

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.