David Ascher writes:
Terminology point: I know that LiskovViolation is technically correct, but I'd really prefer it if exception names (which are sometimes all users get to see) were more informative for people w/o deep technical background. Would that be possible?
I don't see how. Googling on Liskov immediately brings up clear and understandable descriptions of the principle that's being violated. I can't imagine summarizing the issue more concisely than that! What would you suggest? Including better explanations in the documentation is a must, but "LiskovViolation" in the exception name seems unbeatably clear and concise.
Clearly, I disagree.
My point is that it'd be nice if we could come up with an exception name which could be grokkable without requiring 1) Google, 2) relatively high-level understanding of type theory.
Googling on Liskov brings up things like:
http://c2.com/cgi/wiki?LiskovSubstitutionPrinciple
"""What is wanted here is something like the following substitution property: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T." - BarbaraLiskov, Data Abstraction and Hierarchy, SIGPLAN Notices, 23,5 (May, 1988)."""
If you think that that is clear and understandable to the majority of the Python community, you clearly have a different perspective on that community. I have (almost) no doubt that all Python-dev'ers understand it, but maybe we should ask someone like Anna Ravenscroft or Mark Lutz if they thinks it'd be appropriate from a novice user's POV. I'm quite sure that the experts could understand a more pedestrian name, and quite sure that the reverse isn't true.
I also think that the term "violation" isn't necessarily the best word to add to the Python namespace, when error or exception would do just fine.
In addition, to say that it's unbeatably clear without a discussion of alternatives (or if I've missed it, please let me know) seems weird.
The point is broader, though -- when I get my turn in the time machine, I'll lobby for replacing NameError with UndefinedVariable or something similar (or more useful still). The former is confusing to novices, and while it can be learned, that's yet another bit of learning which is, IMO, unnecessary, even though it may be technically more correct.
--david ascher _______________________________________________ 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
