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

Uche Ogbuji uogbuji@fourthought.com
Mon, 26 Jun 2000 18:47:50 -0600


Tom Passim:

> Jim Fulton continued the attributes thread -
> 
> I still don't see why anyone is still arguing about whether the DOM rec
> makes Python use attributes.  I doesn't.  In fact, it says that what are
> called "attributes" in the IDL definitions are NOT supposed to be attributes
> in implementations, and that the get/set accessor functions don't have to
> store/retrieve from actual objects, let alone attributes of objects.
> 
> So can we at least lay this part of it to rest?  Now if most people think it
> is more 'Pythonic' to use attributes, or if there are clearcut performance
> benefits, then we have a basis for discussion. But let's quit talking about
> whether the DOM rec makes us do attributes.

Now I have no idea what you lot are arguing.  The first argument was against 
leading underscore because it's "not Python idiom".  The point was made that 
we should simply cock a snook at the Python/CORBA binding.  Once that point 
was allowed, the same lot are arguing against using attributes, which are 
indisputable Python idiom on the grounds that it goes against the spirit of 
the W3C spec.

I hope I can be blunt without antagonism, but it seems as if a particular goal 
is in mind: i.e. DOM attribute access through accessor/mutators only, and any 
available argument is being thrown at that goal.

I'll note that I claim to have no agenda except to do what's sensible for 
Python and DOM (we've already put a great deal of work into making 4DOM 
conform to the earlier list consensus, and we could put in more work if it 
made sense.)

The course that does make sense is to allow attribute access only because it's 
most Pythonic.


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