In article <683c84d8-d916-4b63-b4b2-92cd2763e...@googlegroups.com>,
wxjmfa...@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?
--
https://mail.python.org/mailman/listinfo/python-list
