When using
  print >> f, "Hello"
on a file f opened for reading, no exception is raised.  Is this normal?

This situation has to be contrasted with
  f.write("Hello")
which raises an exception.

Details with Python 2.5 (r25:51908, Sep 24 206) on OS X 10.4.8 / darwin 8.8.0:

In [1]: f=open("start.01")
In [2]: f.write("Hello")
<type 'exceptions.IOError'>: [Errno 9] Bad file descriptor
In [3]: print >> f, "Hello"
In [4]: f.close()

NB: file f is not modified, despite the "print" statement yielding no error, above.

If this happens, it's a bug. Though it doesn't seem to occur under Linux here.

Interesting point, about Linux.   The incorrect behavior is even seen in the  default python 2.3 that ships with Mac OS X!

I verified this behavior on my Mac with /usr/bin/python, Python 2.5 and
Python 2.6a0, both built from SVN.

Skip

There seem to be multiple problems here. AFAICT,

print >>f, 3

fails on both Linux and OSX. This is because this uses fprintf to put out the number, which, in turn, returns -1. This result is ignored; instead Python expects ferror() to be set. However, ferror doesn't get set.

For printing strings, fwrite is used. On both Linux and OSX, fwrite will return 0. On Linux, in addition, ferror gets set; on OSX, it doesn't.

Reading C99, I can't figure out which of these systems is behaving correctly in what cases. The definition of ferror is that it returns the "error indicator" of the stream, and only fseek, fputc (+putc), and fflush are explicitly documented to set the error indicator. However, the error indicator is also documented to be set that it "records whether a  read/write error  has  occurred", and write is documented to return a number smaller than the requested only if an error occurred. Likewise, fprintf is document to return an negative value "if an  output  or  encoding error occurred."

Putting these all together, ISTM that both Linux and OSX implement fprintf incorrectly. To work around, Python could check the result of fprintf and fwrite in all places; this might become a large change.

Just for reference: with Fink Python 2.5 (r25:51908, Sep 24 2006) on OS X 10.4.8 / darwin 8.8.0 for Intel Macs, "print >>f, 3" is also silently (and incorrectly) accepted when f is only opened for reading.

On Linux both 2.5 and 2.6 are raising an exception:

>>> f = open("/etc/passwd")
>>> print >>f, "Hello"
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 9] Bad file descriptor

Can anyone confirm this for Mac?

This issue is still present on OSX:

Python 2.6.1+ (release26-maint:70603, Mar 26 2009, 08:38:03) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> f = open("/dev/null")
>>> print >>f, "hello"
>>> f = open("/etc/hosts")
>>> print >>f, "world"
>>> 


This is a 2.6.x build from earlier this week.

<http://www.opengroup.org/onlinepubs/9699919799/functions/printf.html> 
claims fprintf should return a negative value when there is an output 
error (the same claims is in the manpage of fprintf on OSX 10.6).

Neither document refers to the error indicator. I'm afraid Martin is right 
that that the return value of all calls to fprintf (and fwrite) need to be  
explicitly checked, which is a very large patch.

I've assumed this is still a problem on OS X.

At least for the original test case, the Python 3 equivalent does fail on OS X:

$ python3.1
Python 3.1.2 (r312:79360M, Mar 24 2010, 01:33:18) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> f = open('/dev/null')
>>> print('Hello',file=f)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: not writable
>>> 

Perhaps this can be closed as "wont fix" for Python 2 and, if necessary, open a separate issue for checking fprintf and fwrite return values?

This is not an issue for 3.x because the io library doesn't use stdio.

I'd say this is unlikely to get fixed in 2.7 as every call to stdio functions needs to be checked and updated.