"Andrew Koenig" <[EMAIL PROTECTED]> writes:
> "Lonnie Princehouse" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
> > If you try this sort of inheritance, I'd recommend writing down the
> > formal grammar before you start writing classes. Don't try to define
> > the grammar through the inheritance hierarchy; it's too easy to
> > accidentally build a hierarchy that can't be translated into a
> > single-pass-parsable grammar...
>
> Understood. I was using expression trees as a contrived example, and really
> want to know about the Python community's stylistic preferences for defing
> such hierarchies that don't absolutely need a root.
Oddly enough, I've just been pondering the same question (albeit for
Perl, but the same reasoning applies). The only cases I've found
useful thus far are:
- implementation inheritance (in the case of default methods in a
callback interface class):
class CallbackInterface:
def handleEvent(self, event):
"""Handle an event"""
pass
def handleSignal(self, signal):
"""Handle a signal"""
pass
This also helps to document what's expected of callback classes,
even though they don't _have_ to inherit CallbackInterface
(enforcing this through isinstance() in the calling class would be
rude).
- hierarchies of exception classes (allowing one to catch general
classes of exceptions, since except implicitly uses isinstance(),
rather than a specific class). Of course, Python already has a
hierarchy of exceptions. I had to implement my own for Perl.
>From a brief skim of http://www.python.org/moin/PythonThreeDotOh it
looks like interfaces _may_ be added to Python 3.0, but they sound
more like (IIRC) ML's signatures and C++'s Standard Library
requirements i.e. a requirement that the class implements certain
functions, rather than a requirement to inherit from a particular base
class.
Guy.
--
http://mail.python.org/mailman/listinfo/python-list
