On 2018-05-20 16:36:12 -0400, Richard Damon wrote: > 2) Try to maximize portability by not only looking at the specs, but > also common implementations, and choosing the options that maximize the > acceptability of your output to tools that don't fully meet the specs. > Also, if a common implementation generates something not quite to the > standard, try to make it so you can accept that output too.
This is the well-known "be conservative in what you send and liberal in what you accept" principle. It has fallen into disfavour over the last decade or so. There are several reasons: * Being liberal in what you accept is problematic because you are accepting input which has no specified meaning and interpret it as you see fit - but there is no guarantee that this is the interpretation that the sender intended. This may result in silent data loss. In many cases an error message is better. * Accepting non-standard input is also problematic because such input is probably not well-tested. The code is much more likely to contain bugs, maybe even security-critical bugs. * If some features of a spec are rarely used, programmers may not implement them. When they are needed, they won't work. A recent example is that the TLS working group found that they can't use the version number field to signal the version number because too many implementations got it wrong (I have no idea how that happened. We are already on the 6th version and all previous upgrades used the version field). Of course, if a popular implementation has known bugs you may have no choice but make concessions. hp -- _ | Peter J. Holzer | we build much bigger, better disasters now |_|_) | | because we have much more sophisticated | | | h...@hjp.at | management tools. __/ | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
signature.asc
Description: PGP signature
-- https://mail.python.org/mailman/listinfo/python-list