[XML-SIG] foo.bar vs. foo.get_bar()

[Ken MacLeod]

uche.ogbuji@fourthought.com writes:

> > But now that I examine the heart of the matter, I guess it's not
> > as bad as I'd thought.  We have not been planning to implement
> > readonly nodes in 4DOM, and we'd leave string-overflow issues to
> > the Python interpreter, so actually we wouldn't need to use
> > __[g/s]etattr__ for Node, and this really brightens things.  Node,
> > Element and Text would be hook-free, and another common class,
> > Attr, would only need the hook if we insisted on arcane W3C rules
> > with regard to specified attributes which don't make much sense
> > without DTD support anyway.
> 
> Well, scratch that after all.  I forgot all about
> DOM_HIERARCHY_REQUEST_ERROR.  That puts Node squarely back into the
> "needs __[g/s]etattr__" camp again.

I don't understand why raising a different exception is a problem with
attributes or how get/set methods make the problem any simpler to grok.

Martin v. Loewis suggests in his post that method syntax makes a
broader range of exceptions "more obvious".  Why would that be?  When
you read the library reference on a module that raises exceptions,
you're going to see the exceptions listed regardless of whether
they're through accessor syntax or method syntax.  Martin states that
one "normally" should only expect AttributeError exceptions from
attribute access.  A quick glance through the library reference shows
that "anydbm" (and it's variants) use other exceptions, I'm sure there
are more examples.

-- 
  Ken MacLeod
  ken@bitsko.slc.ut.us