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

[Uche Ogbuji]

> Jim Fulton wrote:

> > The abstraction of attribute access to allow computation *is* a Python
> > idiom, but so is use of accessor functions.  Avoidance of circular references
> > is *certainly* a common Python design practice.  There are techniques for
> > implementing the DOM API that avoid circular references that require
> > compting some DOM attributes. Requiring that DOM attributes be published
> > as Python attributes makes this harder.
> 
> Avoiding circular references in a DOM environment is hard and almost
> always has a negative impact on performance. If your implementors are
> "up to" doing all of this proxy magic, using attribute accessor
> functions will be comparitavely a snap.
> 
> Or if *you* are implementing the proxy for them, then you can implement
> the attribute accessor functions for them.
> 
> Note also that the Python bug of having trouble with circular references
> is scheduled to be 
> "experimentally" fixed in 1.6 and totally fixed in 1.7. I am relucatant
> to design around it. If we put our heads together, the efficiency hit of
> accessor functions could also be solved in the 1.7 timeline (by making
> them a first-class language feature).


I'll note that IMO the whole circular references argument for a particular DOM 
implementation is a red herring.  We have a huge project running at a 
client's: well over 500,000 lines of Python, long-running required, etc.  It 
uses 4DOM and other code that can introduce circular references, but a few 
hours with Cyclops led us very quickly to any remaining memory leaks.

It's not that hard of a problem with explicit freeing.  Anyone running a 
long-running process, whether in C++, Java or Python, had better be 
sophisticated enough to be able to debug memory allocation errors, 
garbage-collection latency, and curcular references respectively.  (As an 
aside, C++ has tools, Nu-Mega, Purify... to help and Python has tools: Plumbo, 
Cyclops to help... it looks as if Java is the only case in which you're just 
SOL; yet another reason for me to dislike Java).

> > I question the value of list consensus without follow through. I, as a DOM
> > implementor have no way of knowing what the list consensus was unless I
> > happened to be paying attention at the time, which I wasn't. If there was
> > consensus, then it should be published.
> 
> You are asking for a more formal process than is used in the Python
> world. I don't think that there isn't even formal documentation for the
> "file" interface used in hundreds of places. comp.lang.python and /lib
> are the documentation. In open source land, "go look at the code" is a
> vald answer (though sometimes suboptimal).

Quite agreed.  I do agree that some effort at documenting would be nice, but 
that's the nature of the OSS beast.  Pretty much everyone is a volunteer so as 
much documentation gets done as there are willing hands to do it.  The only 
other way is to give one entity (say, Sun) a stranglehold on the process, and 
in that case they have to do all the work

> > When I asked about the API a few days ago, there didn't seem to me
> > to be much consensus about what the Python DOM API actually is.
> 
> I believe that there was consensus among people who have implemented
> DOMs. I expressed the opinion that I wasn't entirely happy with the
> leading underscore thing, but that's what I implemented in my DOM
> anyhow.
> 
> As far as I know, the three Python DOMs all allowed the use of either
> methods or direct attribute access.

Yes.

-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +01 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python