Phillip writes:
> 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...
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 abou
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/l
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 particul
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 document
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?
On
On Wed, 12 Jan 2005 19:49:06 -0500, Phillip J. Eby
<[EMAIL PROTECTED]> wrote:
> 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.
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 compute
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 clear
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
Skip Montanaro <[EMAIL PROTECTED]> writes:
> 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 docum
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> programmi
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 Googl
>>> 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 do
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
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 Unbound
> 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,
>
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
18 matches
Mail list logo
