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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
