Nice quote

Jeremy Bowers jerf at
Sun Mar 30 17:38:39 CEST 2003

On Sat, 29 Mar 2003 07:54:58 -0500, Peter wrote:
> Jeremy Bowers wrote:
>> Would somebody amplify on this please? What XML library do we have
>> that's easier to use then DOM or SAX for real world tasks that doesn't
>> require reading the whole file into memory to work?
> I'm fairly sure the context you omitted would show that the comment above
> didn't imply Python folks have some magic new library that solves the XML
> world's problems.  It seemed to be a statement made partly in contrast to
> the previous statements about Perl's "a zillion ways to do it" and the
> difficulties that was causing XML developers using Perl, and partly in
> contrast to implied other difficulties with XML using other languages.
> Basically, he was conveying that Python people don't find processing XML
> to be a huge problem in any particular way, and I think that's a fair
> assessment.  IMHO.

I didn't take his statement that way because it doesn't make sense some to
me. I've done SAX and DOM in both Perl and Python and they are equal pains
in the ass.

You may consider XML processing not a particular pain but I think that's
more a personal judgment then anything else, because I don't see Python
granting a huge advantage over Perl. The criticisms Tim Bray leveled
against current XML programming paradigms still seems to hold in Python as
well as anything else. At best Python XML processing is at most a small
linear improvement over Perl. 

This is also my basic reply to Cameron Laird's comment; unless he's
specifically referring to corner cases where you might need to do
something hairy that is easy in Python and hard in Perl, the two languages
are reasonably similar in my opinion. This *could* be a side effect of
the fact that I use Perl in a large project, and I tend to use it in a
very Pythonic way because that's my solution to writing maintainable Perl
code; it may be the case that using more Perl-ish idioms makes it harder.

Both are easier then C++ or Java just because of the more flexible, less
B&D object models.

The gnosis.xml packages *are* easier then standard DOM processing, and at
least reduce XML to relatively straight-forward tree processing, though as
the author of those utilities mentioned, I doubt Tim Bray was thinking of
those since Tim doesn't know Python. However it's possible that the
"Python people" mailing Tim may have been thinking of that.

I emphasize that I'm posting this to explore an issue and enhance my
understanding of the issues, and hopefully other's understanding as well.
I'm not trying to be combative. Since we're trying to interpret somebody
else's words who isn't right here to clarify, there isn't really a right

I'm still probably going to noodle around more later with a new library
for Python that will actually construct an object model out of objects you
provide for it, but it would be a long time before it would be publicly
available because I'd want to use it in a lot of situations before I could
be confident it was powerful enough.

More information about the Python-list mailing list