[Python-Dev] Re: PEP 246: LiskovViolation as a name

David Ascher DavidA at ActiveState.com
Wed Jan 12 00:13:43 CET 2005


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


More information about the Python-Dev mailing list