On 2005 Jan 11, at 20:44, Phillip J. Eby wrote: ...
If we're just recomending that people design for transitivity, then I
don't have a problem (although see Alex's fairly good point illustrated
with LotsOfInfo, PersonName, and FullName -- I found it convincing).
It's a bit misleading, however; if the target protocol allows for "nulls", then it's allowed to have nulls. If it doesn't allow nulls, then the adaptation is broken. Either way, it seems to me to work out, you just have to decide which way you want it.
NULLs are allowed, but *PRAGMATICALLY* they shouldn't be used except where there's no alternative.
Is the concept of *PRAGMATICS* so deucedly HARD for all of your eggheads?! Maybe a full-credits course in linguistics should be mandatory for CS major or wherever you got your sheepskin[s].
In terms of syntax and semantics, a TCP/IP stack which just dropped all packet instantly would be compliant with the standards. No GUARANTEE that any given packet will be delivered is ever written down anywhere, after all.
The reason such a TCP/IP stack would NOT be a SENSIBLE implementation of the standards is PRAGMATICS. The stack is supposed to do a best-effort ATTEMPT to deliver packets, dammit! That may be hard to formalize mathematically, but it makes all the difference in the world between a silly joke and a real-world tool.
My best example of pragmatics in linguistics: if I state...:
""" I never strangle python-dev posters with the initials PJE in months with an "R" in them """
I am saying nothing that is false or incorrect or misleading, in terms of syntax and semantics. This assertion is grammatically correct and semantically true.
Does this mean you should worry come May...? Not necessarily, because the assertion is _pragmatically_ dubious. *PRAGMATICALLY*, in all natural languages, when I state "I never do X under condition Y" there's an implication that "condition Y" DOES have something to do with the case -- that if condition Y DOESN'T hold then my assurance about not doing X weakens. If condition Y has nothing to do with my doing or not doing X, then by the PRAGMATICS of natural language I'm NOT supposed to juxtapose the two things -- even though both syntactically and semantically it's perfectly correct to do so.
Network protocol specs, programming language, libraries, etc, have pragmatics, too. They're way harder to formalize, but that doesn't mean they can be blithely ignored in the real world.
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.
Alex
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
