[XML-SIG] Ugh! Why are DOM access methods spelled with a leading
Tue, 27 Jun 2000 14:48:49 -0600
> 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
> As far as I know, the three Python DOMs all allowed the use of either
> methods or direct attribute access.
Uche Ogbuji Principal Consultant
email@example.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