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. -- Michael Chermside
Michael Chermside wrote:
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
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.
How about SubstitutabilityError?
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.
We did that for UnboundLocalError, which subclasses NameError. Perhaps we can rename NameError to UnboundVariableError (and add NameError as an alias for b/w compat). -- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
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.
How about SubstitutabilityError?
That would be far, far better, yes.
We did that for UnboundLocalError, which subclasses NameError. Perhaps we can rename NameError to UnboundVariableError (and add NameError as an alias for b/w compat).
Sure, although (and here I'm pushing it, I know, and I should have argued it way back then), the notion of 'unbound' is possibly too low-level still. 'Unknown' would probably carry much more meaning to those people who most need it. But yes, you're catching my drift. --david
Guido van Rossum wrote:
The point is broader, though -- when I get my turn in the time machine, I'll lobby for replacing NameError with UndefinedVariable or something
Strange, my blog reading just hit upon http://blogs.zdnet.com/open-source/index.php?p=93 ... "Perhaps as open source developers are making their resolutions for 2005, they could add human-readable error codes to their list? " :-) --david
>>> 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. David> Clearly, I disagree. I had never heard the term before and consulted the Google oracle as well. I found this more readable definition: Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it. here: http://www.compulink.co.uk/~querrid/STANDARD/lsp.htm Of course, the situations in which a Liskov violation can occur can be a bit subtle. David> My point is that it'd be nice if we could come up with an David> exception name which could be grokkable without requiring 1) David> Google, 2) relatively high-level understanding of type theory. I suspect if there was a succinct way to convey the concept in two or three words it would already be in common use. The alternative seems to be to make sure it's properly docstringed and added to the tutorial's glossary: >>> help(lv.LiskovViolation) Help on class LiskovViolation in module lv: class LiskovViolation(exceptions.Exception) | Functions that use pointers or references to base classes must be | able to use objects of derived classes without knowing it. | ... I suspect there's something to be said for exposing the user base to a little bit of software engineering terminology every now and then. A couple years ago I suspect most of us had never heard of list comprehensions, and we all bat the term about without a second thought now. Skip
participants (4)
-
David Ascher
-
Guido van Rossum
-
Michael Chermside
-
Skip Montanaro