Inefficiency of __getattr__

Kragen Sitaker kragen at
Wed Oct 4 11:47:02 CEST 2000

In article <8rep3p$e93$1 at>,  <lss at> wrote:
>In the Python example, there's no way of easily telling what this
>function really wants for its 'newchild' parameter. Sure, anyone can
>figure out it's probably a DOM node, but what interface should this DOM
>node have in order for the method to work? Can I pass in my own DOM
>node implementation and expect it to work? Not unless I either subclass
>an existing node implementation from the same API (which can be
>dangerous or quite a hassle at times) or actually read the entire
>function and check exactly what attributes will need to be accessed
>from the node object (a bit more work than most would be willing to

It's worse than that --- you need to understand what is expected of
those attributes, semantically.  And Java interfaces don't give you

The difference in this case is that, with static typing and an
interface, you find out at compile-time that your DOM node doesn't
implement the right interface.  With dynamic typing, you find out as
soon as you run the regression tests the first time.  Which you were
going to do anyway, right?  I mean, just because your Java compiler
couldn't find your bugs doesn't mean they're not there :)  Especially
when the interface provides no machine-readable documentation on its
semantics, as Java's doesn't.

>In the java example, Node is an interface, org.w3c.dom.Node. This
>interface specifies not only the exact interface of the method itself,
>but also indirectly the exact interfaces necessary for all objects
>passed to and from the function. Thus I don't have to worry about
>determining the necessary interfaces for the objects I pass in to the
>method, the compiler will do it for me.

To write a working implementation of org.w3c.dom.Node, you need a
natural-language explanation of the semantics of the interface as well
as a specification of the names of its members and their parameter and
return types.  This is true in both Python and Java.

In both cases, you need automated unit tests with good coverage to
verify even minimal conformance to the semantic requirements of the
interface.  Such a set of tests will also tell you when you are passing
the wrong number of arguments, or arguments of the wrong type.  You can
typically run a few dozen to a few thousand individual tests per
second, so the extra run time is minimal.

I've heard that the Eiffel guys use preconditions and postconditions to
help with this, but preconditions and postconditions don't get verified
at compile time --- just run time.

>In the case of Java interfaces, there is an even more important
>advantage: they're standardized. Simply because the org.w3c.dom.Node
>interface exists and pretty much all Java DOM-based libraries use it I
>can make my own DOM node implementation (which implements this
>interface) and make it work with any XPath implementation available,
>for example.

I notice that Python contains a number of classes that implement the
file-object interface, which work anywhere you could use a file object

>In Python, I would have to engage in extensive studies of
>the XPath library and adapt my DOM node implementation's interfaces for
>that particular library, and in the end it probably wouldn't work with
>any other available XPath implementations. Providing similar interface
>functionality in Python would be pretty easy, but what's the point if
>only I use interfaces and they aren't standardized? I think interfaces
>could be adapted to work with dynamic typing in Python also, however.
>The trick would be to get people to use them and agree on which
>interfaces to use.

Whenever I see a decent library, in Python or any other language, it
includes documentation of its interface that is sufficient to write
code implementing the same interface.  I'm not convinced that Java's
'interface' construct is a significant help in writing this
documentation, although I have to admit I haven't written Java.

<kragen at>       Kragen Sitaker     <>
Perilous to all of us are the devices of an art deeper than we ourselves
                -- Gandalf the Grey [J.R.R. Tolkien, "Lord of the Rings"]

More information about the Python-list mailing list