[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