On 4/17/07, Jason Orendorff wrote:

Surely nobody is subclassing these classes. You don't subclass DOM interfaces--the DOM doesn't work that way. So this change should be OK. Right?

People are definitely subclassing those classes: http://www.google.com/codesearch?hl=en&lr=&q=class%5Cs%2B.%2B%5C%28.*minidom%5C.&btnG=Search Whether any of those uses will break if switched to new-style class, I can't say. Collin Winter

Perhaps a rewrite could target 3.0 and 2.6 could use a backported version of this *if* py3k compatibility mode is enabled? I'd love to see at least the 3.0 version cleaned up. --Guido On 4/17/07, Fred L. Drake, Jr. wrote:

On Tuesday 17 April 2007 22:37, Jason Orendorff wrote:

...

The right way to implement these quirks is using new-style classes and properties. Right now minidom uses old-style classes and lots of hackery, and it's pretty broken. (Another example--there is an Attr._set_prefix method, but it is *not* called from __setattr__.)

Yes, it's truly vile. Better than it used to be, but....

There's also some vague attempt at supporting the Python CORBA IDL mapping, since the W3C DOM specifications use that. I expect the support is incomplete at best.

...

Surely nobody is subclassing these classes. You don't subclass DOM interfaces--the DOM doesn't work that way. So this change should be OK. Right?

There are people who've tried building new DOM implementations by subclassing the minidom classes to get most of the behavior. I'm don't know the status of any of these implementations, but changes to these classes have proved difficult due to this and the possibility of breaking pickles (amazed me, that one did!).

I'd love to see a sane implementation, using new-style classes and properties, but as long as we've got to support existing applications, we're pretty well hosed as far as xml.dom.minidom is concerned.

A new DOM implementation conforming to the W3C recommendations would be nice, but I'd really rather see an XML object model that doesn't suck, but that supports as much of the information found in the W3C DOM as possible. Something based more on the ElementTree API, perhaps. The value of the W3C-approved API has certainly turned out to be more decoy than anything.

-Fred

-- Fred L. Drake, Jr. <fdrake at acm.org> _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

Great -- if you target 2.6, it'll automatically be merged into 3.0 the next time somebody runs svnmerge. (Thomas?) --Guido On 4/18/07, Jason Orendorff wrote:

On 4/17/07, Guido van Rossum wrote:

...

Perhaps a rewrite could target 3.0 and 2.6 could use a backported version of this *if* py3k compatibility mode is enabled? I'd love to see at least the 3.0 version cleaned up.

A lot of these bugs can be fixed without forking. I've been conservative so far. I looked at a diff this morning. Even pickled documents shouldn't break.

If this patch lands, I can look at further cleanup after that.

Thanks everyone, -j

-- --Guido van Rossum (home page: http://www.python.org/~guido/)