Dave Angel wrote:
Jean-Michel Pichavant wrote:
<div class="moz-text-flowed" style="font-family: -moz-fixed">Nigel
Rantor wrote:
Jean-Michel Pichavant wrote:
Your solution will work, for sure. The problem is that it will dumb
down the Base class interface, multiplying the number of methods by
2. This would not be an issue in many cases, in mine there's
already too much meaningful methods in my class for me to add
artificial ones.
Thanks for the tip anyway.
I suggest you reconsider.
You asked a question and have been given a standard way of achieving
the desired outcome.
It's common in OO to use a Template pattern like this.
If you're not interested in finding out how loads of people have
already solved the problem then why ask?
The methods that require overriding can be prefixed with an
underscore so that people get a hint that they are an implementation
detail rather than part of the public interface.
I don't see your problem, other than a vague aesthetic unease.
Regards,
n
I understand how refuting some obvious solution may look just stupid.
You're right, I shouldn't have asked.
By the way I'd like to know if I am I alone to find that
class Stream:
def start
def stop
def reset
is better than
class Stream:
def start
def _start
def stop
def _stop
def reset
def _reset
(try to figure out with 20+ methods)
What you call aesthetic may sometimes fall into readability.
JM
</div>
Usually when one defines an abstract base class, one expects many
people will derive from it, as opposed to only one having to write
it. So if the base must be "ugly" according to some definition, so be
it. Aesthetics are quite subjective.
Nigel's approach has another benefit not stated, which is to keep the
child class code simpler. They avoid the need to call any base class
method to access the common logic. The downside is it assumes that
the common logic will always be either at the beginning or always at
the end of the child classes implementation. That's because the base
class has hardcoded where in its implementation to call the child
class method.
I think this is a severe issue.
You prevent the sub class from writing
def foo(self):
pre()
Base.foo(self)
post()
Anyway, without arguing for or against either approach, I'd point out
that you could have an extra formal parameter in the base method,
which is a private signal from the child class that this is the
internal call. Missing such a formal parameter would then trigger the
"missing method in derived class" error message. You'd check such a
parameter the same place as you're now checking the object's type.
DaveA
talking about approaches:
1/
class Interface:
def foo(self):
if self.__class__.foo == Interface.foo:
raise NotImplementedError
2/
class Interface:
def foo(self):
self._foo()
def _foo(sef):
raise NotImplementedError
Are they so different ? They both require about the same amount of extra
characters, they're both readable. The second is a very classic OO
layout, the first is more flexible for the sub classes and spare some
method definition.
This thread may live again, I cannot say but I'd like to thanks all who
gave me their valuable idea on the subject, I mean it. Please don't take
my skepticism as a lack of consideration.
JM
--
http://mail.python.org/mailman/listinfo/python-list
