Status of side-effecting functions in python

[Roy Smith]

In article <683c84d8-d916-4b63-b4b2-92cd2763e260 at googlegroups.com>,
 wxjmfauth at gmail.com wrote:

> Le dimanche 26 octobre 2014 14:41:43 UTC+1, Dan Sommers a écrit :
> > On Sun, 26 Oct 2014 00:45:49 -0700, wxjmfauth wrote:
> > 
> > > Ditto for <fileobj>.write(). Why should it return "something" ?
> > > 
> > >>>> with open('z.txt', 'w') as f:
> > > ...     f.write('abc')
> > > ...     
> > > 3
> > 
> > OTOH, why shouldn't it return something?  In this case, it returns the
> > length of the string written.  This value is analogous to the value
> > returned by the underlying OS function (at least on a POSIX-like system,
> > where write(2) returns the number of bytes written).  This value can be
> > useful for detecting when things have gone wrong; e.g., disk full,
> > network down, pipe broken, etc.  Practicality definitely beats purity.
> > 
> > At one time, on a huge project, millions of lines of C and assembly
> > code, we had a local guideline *not* to write void functions.  The idea
> > was to return something that might be useful later, even if it seemed
> > unlikely now.  A simple success flag was sufficient; as functions grew,
> > often did their failure modes.
> > 
> > Dan
> 
> Yes and no. If something goes wrong in a .write() method,
> is not Python supposed to raise an error? (!)

Define "wrong".  It is not an error for a write() call to consume fewer 
bytes than were requested.  How would you expect this to be handled in 
Python?  Raise DataPartiallyWrittenError?