RE: [Python-Dev] Re: PEP 246: LiskovViolation as a name
I wrote:
I don't see how [LiskovViolation could have a more descriptive name]. Googling on Liskov immediately brings up clear and understandable descriptions of the principle
David writes:
Clearly, I disagree. [...]
Skip writes:
I had never heard the term before and consulted the Google oracle as well.
This must be one of those cases where I am mislead by my background... I thought of Liskov substitution principle as a piece of basic CS background that everyone learned in school (or from the net, or wherever they learned programming). Clearly, that's not true. Guido writes:
How about SubstitutabilityError?
It would be less precise and informative to ME but apparently more so to a beginner. Obviously, we should support the beginner! -- Michael Chermside
Michael> This must be one of those cases where I am mislead by my Michael> background... I thought of Liskov substitution principle as a Michael> piece of basic CS background that everyone learned in school Michael> (or from the net, or wherever they learned Michael> programming). Clearly, that's not true. Note that some us were long out of school by the time Barbara Liskov first published the idea (in 1988 according to http://c2.com/cgi/wiki?LiskovSubstitutionPrinciple). Also, since it pertains to OO programming it was probably not taught widely until the mid-90s. That means a fair number of people will have never heard about it. Michael> Guido writes: >> How about SubstitutabilityError? I don't think that's any better. At the very least, people can Google for "Liskov violation" to educate themselves. I'm not sure that the results of a Google search for "Subtitutability Error" will be any clearer. Michael> It would be less precise and informative to ME but apparently Michael> more so to a beginner. Obviously, we should support the Michael> beginner! I don't think that's appropriate in this case. Liskov violation is something precise. I don't think that changing what you call it will help beginners understand it any better in this case. I say leave it as it and make sure it's properly documented. Skip
Skip Montanaro
I don't think that's appropriate in this case. Liskov violation is something precise. I don't think that changing what you call it will help beginners understand it any better in this case. I say leave it as it and make sure it's properly documented.
+1 -- KBK
Skip Montanaro wrote:
Michael> This must be one of those cases where I am mislead by my Michael> background... I thought of Liskov substitution principle Michael> as a piece of basic CS background that everyone learned Michael> in school (or from the net, or wherever they learned Michael> programming). Clearly, that's not true.
Note that some us were long out of school by the time Barbara Liskov first published the idea (in 1988 according to http://c2.com/cgi/wiki?LiskovSubstitutionPrinciple). Also, since it pertains to OO programming it was probably not taught widely until the mid-90s. That means a fair number of people will have never heard about it.
...and then there are those Python users who have no formal CS background at all. Python is used quite a bit by people who's main job is not programming. <sidebar>I'm one of those, and whatever I know about CS, I owe it mostly to the Python community. I learned an awful lot just by hanging out on various Python mailing lists.</sidebar>
Michael> Guido writes: >> How about SubstitutabilityError?
I don't think that's any better. At the very least, people can Google for "Liskov violation" to educate themselves. I'm not sure that the results of a Google search for "Subtitutability Error" will be any clearer.
Well, with a bit of luck Google will point to the Python documentation then... Just
Just van Rossum wrote:
...and then there are those Python users who have no formal CS background at all. Python is used quite a bit by people who's main job is not programming.
...and among us who do programming as a main job, I can assure that I'm not the only one who, if told by a computer that something I did was a LSP violation, would take that computer out in the backyard and shoot it. or at least hit it with a shovel, or something. </F>
At 02:03 PM 1/12/05 -0600, Skip Montanaro wrote:
I don't think that's appropriate in this case. Liskov violation is something precise. I don't think that changing what you call it will help beginners understand it any better in this case. I say leave it as it and make sure it's properly documented.
Actually, the whole discussion is kind of backwards; you should never *get* a Liskov violation error, because it's raised strictly for control flow inside of __conform__ and caught by adapt(). So the *only* way you can see this error is if you call __conform__ directly, and somebody added code like this: raise LiskovViolation So, it's not something you need to worry about a newbie seeing. The *real* problem with the name is knowing that you need to use it in the first place! IMO, it's simpler to handle this use case by letting __conform__ return None, since this allows people to follow the One Obvious Way to not conform to a particular protocol. Then, there isn't a need to even worry about the exception name in the first place, either...
On Wed, 12 Jan 2005 19:49:06 -0500, Phillip J. Eby
So the *only* way you can see this error is if you call __conform__ directly, and somebody added code like this:
raise LiskovViolation
So, it's not something you need to worry about a newbie seeing. The *real* problem with the name is knowing that you need to use it in the first place!
IMO, it's simpler to handle this use case by letting __conform__ return None, since this allows people to follow the One Obvious Way to not conform to a particular protocol.
Not that my opinion counts for much =), but returning None does seem much simpler to me. I also haven't seen any arguments against this route of handling protocol nonconformance... Is there a particular advantage to the exception-raising scheme? Steve -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy
At 05:54 PM 1/12/05 -0700, Steven Bethard wrote:
Not that my opinion counts for much =), but returning None does seem much simpler to me. I also haven't seen any arguments against this route of handling protocol nonconformance... Is there a particular advantage to the exception-raising scheme?
Only if there's any objection to giving the 'object' type a default __conform__ method that returns 'self' if 'isinstance(protocol,ClassTypes) and isinstance(self,protocol)'.
On 2005 Jan 13, at 02:18, Phillip J. Eby wrote:
At 05:54 PM 1/12/05 -0700, Steven Bethard wrote:
Not that my opinion counts for much =), but returning None does seem much simpler to me. I also haven't seen any arguments against this route of handling protocol nonconformance... Is there a particular advantage to the exception-raising scheme?
Only if there's any objection to giving the 'object' type a default __conform__ method that returns 'self' if 'isinstance(protocol,ClassTypes) and isinstance(self,protocol)'.
In the spirit of minimalism in which I propose to rewrite PEP 246 (as per my latest post: make a simple, noninvasive, unassuming PEP 246 while new ``copernical revolution'' ideas which you proposed mature in another PEP), I'd rather not make a change to built-in ``object'' a prereq for PEP 246; so, I think the reference implementation should avoid assuming such changes, if it's at all possible to avoid them (while, no doubt, indicating the desirability of such changes for simplification and acceleration). Incidentally, "get this specialmethod from the type (with specialcasing for classic classes &c)" is a primitive that PEP 246 needs as much as, say, copy.py needs it. In the light of the recent discussions of how to fix copy.py etc, I'm unsure about what to assume there, in a rewrite of PEP 246: that getattr(obj, '__aspecial__', None) always does the right thing via special descriptors, that I must spell everything out, or, what else...? If anybody has advice or feedback on these points, it will be welcome! Alex
At 09:00 AM 1/13/05 +0100, Alex Martelli wrote:
Incidentally, "get this specialmethod from the type (with specialcasing for classic classes &c)" is a primitive that PEP 246 needs as much as, say, copy.py needs it. In the light of the recent discussions of how to fix copy.py etc, I'm unsure about what to assume there, in a rewrite of PEP 246: that getattr(obj, '__aspecial__', None) always does the right thing via special descriptors, that I must spell everything out, or, what else...?
I think you can make it a condition that metaclasses with __conform__ or __adapt__ must use a data descriptor like my "metamethod" decorator. Then, there is no metaconfusion since metaconfusion requires a metaclass to exist, and you're requiring that in that case, they must use a descriptor to avoid the problem.
Skip Montanaro wrote:
Michael> Guido writes:
How about SubstitutabilityError?
I don't think that's any better. At the very least, people can Google for "Liskov violation" to educate themselves. I'm not sure that the results of a Google search for "Subtitutability Error" will be any clearer
...
I don't think that's appropriate in this case. Liskov violation is something precise. I don't think that changing what you call it will help beginners understand it any better in this case. I say leave it as it and make sure it's properly documented.
Yes but in order to fall into a Liskov Violation, one will have to use extreme OOP features (as I understand from the ongoing discussion for which, honestly, I understand nothing:). So it's not like it will happen often and when it happens it will make sense to the architects who made such complex things. +1 on SubstitutabilityError or something easier and moreover because of the fact that some people really don't care who Liskov is and what he/she discovered, and whether that same thing would had been discovered anyway 2 mothns later by somebody else if the Liskov person wasn't there. St.
stelios> Yes but in order to fall into a Liskov Violation, one will have stelios> to use extreme OOP features (as I understand from the ongoing stelios> discussion for which, honestly, I understand nothing:). The first example here: http://www.compulink.co.uk/~querrid/STANDARD/lsp.htm Looks pretty un-extreme to me. It may not be detectable without the pep 246 stuff, but I suspect it's pretty common. Skip
"Skip Montanaro"
The first example here: http://www.compulink.co.uk/~querrid/STANDARD/lsp.htm Looks pretty un-extreme to me.
To both summarize and flesh out the square-rectangle example: Q. Is a square 'properly' a rectangle? A. Depends on 'square' and 'rectangle'. * A static, mathematical square is a static, mathematical rectangle just fine, once width and height are aliased (adapted?) to edge. The only 'behaviors' are to report size and possibly derived quantities like diagonal and area. * Similarly, a dynamic, zoomable square is a zoomable rectangle. * But a square cannot 'properly' be a fully dynamic rectangle that can mutate to a dissimilar shape, and must when just one dimension is changed -- unless shape mutation is allowed to fail or unless the square is allowed to mutate itself into a rectangle. So it seems easily possible to introduce Liskov violations when adding behavior to a general superclass. Terry J. Reedy
participants (10)
-
Alex Martelli -
Fredrik Lundh -
Just van Rossum -
kbk＠shore.net -
Michael Chermside -
Phillip J. Eby -
Skip Montanaro -
stelios xanthakis -
Steven Bethard -
Terry Reedy