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

[Jim Fulton]

Paul Prescod wrote:
> 
> 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.

It's not *that* hard. I think that the StructuredTextNG
DOM will provide an interesting examle of this.

> If your implementors are
> "up to" doing all of this proxy magic, using attribute accessor
> functions will be comparitavely a snap.

No, it won't, because __getattr__ doesn't mix well.
I can add a bunch of new methods and mix them in without
much effect on other mixins. This is not true of getattr.
 
> Or if *you* are implementing the proxy for them, then you can implement
> the attribute accessor functions for them.

Not if they have their *own* __getattr__.
 
> 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).

Circular teferences are harmful in other ways that just GC.
For example, deep copy, and similar applications are certainly complicated
by them. In any case, designing an API that encourages memory leaks
in current Python seems like a pretty bad idea to me.
 
> > 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.

But there *is* formal documentation for sequence, mapping, and number
interfaces. There's a DBI spec that provides an interface for 
relational databases. There's a ZODB Storage interface that allows 
people to implement alternate storages for ZODB. Any time you 
need interoperability, you need to define and document interfaces.
 
> In open source land, "go look at the code" is a
> vald answer (though sometimes suboptimal).

Sorry, that just doesn't work. If I looked at the code in
the XML distribution I'd have alot of trouble figuring
out what the Python DOM API is.

> > 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. 

Hm, I really don't think I believe this. Then again, I'm still not
sure I know what the Python DOM mapping is. I have a sense that the
mapping calls for use of attribute syntax, yet people bothered to defend
the accessor method spelling as though it was in the API.

> 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.

"As far as I know"?

QED :)

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.