On Thu, 31 Mar 2005 20:24:08 GMT, "Andrew Koenig" <[EMAIL PROTECTED]> wrote:
>""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message >news:[EMAIL PROTECTED] > >> You would normally try to avoid type queries, and rely on virtual >> methods instead, if possible. > >Of course. > >> It seems likely for the application >> that code can be shared across different subclasses, for example, >> you might be able to define >> >> def Expr: >> def __str__(self): >> return '%s(%s)' % (self.__class__.__name__, >> ", ".join(map(str, self.operands())) >> >> requiring you only to implement .operands() in the subclasses. > >Indeed. > >> If you can anticipate such common code, it is easier to add >> a base class right away. If you cannot think of a specific >> use case, there is little point in having a common base class. > >So, for example, you don't think it's worth including the base class as a >way of indicating future intent? > If the intent is pretty sure of implementation, I guess it will save some editing to include it at the start (unless you intended to define old-style classes and factor the base class inheritance revisions into some global metaclass hack later (not even really sure that's reliably possible, but pretty sure it would not be the best style ;-) BTW 2.5 may let you mod classes by prefixing a decorator instead of editing the first line. Not sure about the style/semantics tradeoffs there. Regards, Bengt Richter -- http://mail.python.org/mailman/listinfo/python-list
