Status of side-effecting functions in python
wxjmfauth at gmail.com
wxjmfauth at gmail.com
Sun Oct 26 12:26:53 EDT 2014
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? (!)
More information about the Python-list
mailing list