[Python-Dev] PEP 460 reboot

Greg Ewing greg.ewing at canterbury.ac.nz
Wed Jan 15 00:31:10 CET 2014


Guido van Rossum wrote:
> Quite a few people have spoken out in favor of loud
> failures rather than silent "wrong" output. But I think that in the
> specific context of formatting output, there is a long and IMO good
> tradition of producing (slightly) wrong output in favor of more strict
> behavior. Consider for example what to do when a number doesn't fit in
> the given width. Would you rather raise an exception, truncate the
> value, or mess up the formatting?

That depends on the context. If the output is simply a text
file whose lines can grow to accommodate the extra width,
messing up the formatting probably okay.

If it's going into a printed report with a strictly limited
width for each column, and anything that doesn't fit is
going to get graphically clipped away, with no visual
indication that this has happened, it's NOT okay.

If it's going into a text file with defined columns for
each field, which will be read by something that assumes
certain things are in certain columns, it's NOT okay.

If it's going into a binary file as a field consisting
of a length byte followed by some chars, messing up the
formatting is DEFINITELY NOT okay.

This latter kind of situation is the one we're talking
about. If you do something like

    b"%c%s" % (len(data), data)

and data is a str, then the length byte will be correct,
but the data will be (at least) 3 bytes too long. Whatever
reads the file then gets out of step at that point, and
all hell breaks loose.

You do *not* get a nice, easy-to-debug symptom from this
kind of thing. You get "Something is wrong somewhere in
this 50 megabyte jpg file, good luck on finding out what
and why".

-- 
Greg


More information about the Python-Dev mailing list