[XML-SIG] Ugh! Why are DOM access methods spelled with a leading '_'?

[Jim Fulton]

Paul Prescod wrote:
> 
> Jim Fulton wrote:
> >
> >
> > > In 4DOM, we are actually moving away from __getattr__ (for speed).
> >
> > IMO, this is strong evidence that the Python DOM should
> > *not* use attributes for implementing the DOM/IDL attributes
> 
> Direct attribute access is MUCH, MUCH faster than a method call, whethr
> through getattr or not. Under the current implementation we have the
> option of caching attributes for performance. An all method design would
> take that away. Minidom uses direct attributes for 95% of what it does.
> I think I used one getter method to lazily evaluate attributes.

Does minidom create circular references? I don't see how you could
use direct attributes for attributes like parentNode and previousSibling
without creating circularreferences/

> > I'd like it to be as easy as possible for various objects to implement
> > the DOM. (See for example StructuredTextNG.) I'd hate to make implementers
> > go through the pain and performance hit of getattr or dictate an implementation
> > (like caching attributes or otherwise directly storing them, creating
> > memory leaks).
> 
> I guess the question is who do we cater to? Heretofore it has been DOM
> users first, DOM implementors second. I don't think that we should turn
> that around based on the argument that all Python objects will have a
> DOM interface soon.

I agree that this is a tradeoff.  I don't think we should 
dismiss implementation effort.
 
> To me, this looks like Python:
> 
> a=b.childNodes[0].attributes["abc"]
> 
> and this looks like Java:
> 
> a=b.getChildNodes()[0].getAttributes()["abc"]

To me, both look like Python.

> The second grates on me as having interface enforced because of
> implementation limitations. (which is what all of this griping about
> getattr being slow boils down to...isn't it better to fix that problem
> once, for everyone than to work around it a hundred times?) It also
> drives me crazy that the latter always invokes a method call even when
> it is stored underneath as a simple attribute.

The point of an interface is to avoid dictating an implementation.
DOM is certainly an API that cries for alternate implementations.

> Surely there is some imaginative way to make life easier for your
> implementors using base classes. For instance, wouldn't it be nice for
> you to automatically set up the attributes list based on Python
> attributes? Something like:
> 
> def __getattr__( self, name ):
>         if name=="attributes":
>                 keys=self.__dict__.keys()
>                 values=map( str, self.__dict__.values()
>                 return JimsAttributeList( keys, values )
> 
> Encourage them to subclass from you but add some value that they
> wouldn't get otherwise.

__getattr__ is notoriously difficult to mix. I might want to mix this
with other classes that *also* want to use __getattr__. __getattr__-based
implemantations are likely to be too slow, as Mike pointed out.

Jim

--
Jim Fulton           mailto:jim@digicool.com   Python Powered!        
Technical Director   (888) 344-4332            http://www.python.org  
Digital Creations    http://www.digicool.com   http://www.zope.org    

Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email
address may not be added to any commercial mail list with out my
permission.  Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for
repeats.