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

[uche.ogbuji@fourthought.com]

> On the topic of whether to do foo.bar or foo.get_bar(), I would like to
> point out a cautionary tale.  When doing NumPy, Jim Hugunin chose the .foo
> notation (as it happens, only for some attributes, not for all, for
> reasons best left between Jim and his therapist <wink>). While that is
> appealing, it had the problem in the NumPy world that it made subclassing
> from his array type quite difficult. While having a __[g|s]etattr__
> mechanism is fine for a Python 'expert', it is not something that one
> should force users to use if they wish to subclass from a given class.  It
> is too easy to screw up and get stack overflows. 

This is an good point, David, and one I hadn't thought of wrt the 
"node.parent" approach which I've been advocating, and which seems to be very 
popular.

Probably the best response is that newbies can inherit from DOM classes, using 
regular methods for the interface they expose, and just accessign the parent 
attributes as any user would.

class MyNode(Node):
	def foo(self):
		result = my_process(self.parent)
		return result

Of course the fact that MyNode's interface is a hodge-podge of inherited 
attributes and added methods may be confusing to its users.

The real mess comes about if MyNode's programmer wants to use __[g/s]etattr__ 
for whatever reason.

So the list of knocks against "node.parent" is now:

*	Probably slower
*	Complex behavior masked in a supposedly simple attribute access
*	Possible confusion and complexity in sub-classing situations

So far, its main plusses are that it's clean, pythonic, and in close 
correspondence to the W3C API specifications.

Note that I don't like the idea of the Python binding officially supporting 
two approaches, i.e. "node.parent" _and_ "node.get_parent()".  I think it's 
great for implementations to provide alternatives, but the binding should 
require one unequivocally.


-- 
Uche Ogbuji
FourThought LLC, IT Consultants
uche.ogbuji@fourthought.com	(970)481-0805
Software engineering, project management, Intranets and Extranets
http://FourThought.com		http://OpenTechnology.org