[ python-Bugs-1653416 ] print >> f, "Hello" produces no error: normal?

[SourceForge.net]

Bugs item #1653416, was opened at 2007-02-06 17:23
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1653416&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: E.-O. Le Bigot (eolebigot)
Assigned to: Nobody/Anonymous (nobody)
Summary: print >> f, "Hello" produces no error: normal?

Initial Comment:
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.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2007-02-10 00:14

Message:
Logged In: YES 
user_id=21627
Originator: NO

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.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2007-02-06 19:49

Message:
Logged In: YES 
user_id=44345
Originator: NO

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

Skip


----------------------------------------------------------------------

Comment By: E.-O. Le Bigot (eolebigot)
Date: 2007-02-06 18:45

Message:
Logged In: YES 
user_id=1440667
Originator: YES

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


----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-02-06 18:31

Message:
Logged In: YES 
user_id=849994
Originator: NO

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

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1653416&group_id=5470