[Python-Dev] PEP 246, redux
Phillip J. Eby
pje at telecommunity.com
Tue Jan 11 22:08:13 CET 2005
At 09:23 PM 1/11/05 +0100, Alex Martelli wrote:
>Is the concept of *PRAGMATICS* so deucedly HARD for all of your eggheads?!
Hmm. Pot, meet kettle. :)
>Yes, you're ALLOWED to stuff with NULL any field that isn't explicitly
>specified as NOT NULL.
>
>But you should ONLY do so when the information is REALLY missing, NOT when
>you've lost it along the way because you've implemented adapter-chain
>transitivity: dropping information which you COULD have preserved with a
>bit more care (==without transitivity) is a violation of PRAGMATICS, of
>the BEST-EFFORT implication, just as it would be to drop packets once in a
>while in a TCP/IP stack due to some silly programming bug which was passed
>silently.
This is again a misleading analogy. You are comparing end-to-end with
point-to-point. I am saying that if you have a point-to-point connection
that drops all packets of a particular kind, you should not put it into
your network, unless you know that an alternate route exists that can
ensure those packets get through. Otherwise, you are breaking the network.
Thus, I am saying that PRAGMATICALLY, it is silly to create a cable that
drops all ACK packets, for example, and then plug it into your
network. And especially, it's silly to turn around that as a reason that
one should only use end-to-end leased lines, because that packet forwarding
business is dangerously unreliable!
As far as I can tell, you are arguing that you should never use packet
forwarding for communication, because somebody might have a router
somewhere that drops packets. While I am arguing that if a router is known
to drop packets incorrectly, the router is broken and should be removed
from the network, or else bypassed via another route. And, in the cases
where you have a "leased line" direct from point A to point B, your routers
should be smart enough to use that route in place of forwarding from A to C
to D to B, or whatever.
More information about the Python-Dev
mailing list