[XML-SIG] Developer's Day
Thu, 16 Dec 1999 10:02:55 -0800
"Andrew M. Kuchling" wrote:
> * Python revisions come out slowly, once every year or two. XML
> standards have been revolving faster , and we don't want to wait
> until 1.7 for SAX2, or DOM Level2, or other new revisions.
> Keeping the modules out of the core lets them be updated at their
> own pace. A counterargument is that the XML specs are slowing
> down -- add namespace support to SAX, and finalize DOM
> Level 2, and I don't think any other standards are very important
> to basic XML programming.
I agree with your counterargument. :) Anyhow, isn't there a logical
fallacy in your original argument? Why can't we offer a DOM 3 module or
extension after Python ships with DOM 2?
> * We really want a C-based parser to be commonly available.
> sgmlop is the only reasonable choice for this, because I'd be
> against including Expat. To replay some arguments I made against
> including the zlib library in 1.6, what if a C extension requires
> a newer version of the library? Symbol conflicts if you're lucky,
> hard-to-debug problems if you're not.
I don't understand this issue. Why would a C extension build on sgmlop
which is designed to make XML information available to *Python*
> * We can drop various marginal bits of the CVS tree; the xmlarch
> support is probably not of very wide interest, for example.
How about "expat", "mac", "pyexpat", "utils", "windows". There is just
too much stuff there! And I daresay that alot of it has not been
"quality controlled" to the level that we would expect if it were a part
of the real Python library. In other words, there is no single place to
go to get only XML-processing software that works well and works
> I think I'm on the record as saying that Python's major problems now
> aren't language-related, but are with the development environment.
> Language changes (from minor, like 'for i in 1..9', to major, like
> fixing the type/class dichotomy or adding static types) aren't going
> to bring in piles of new users, useful though they might be to
> experienced Pythoneers, large projects, or some other specific
(irrelevant aside: I agree 100% that making things easier to install
will actually improve newbies experience more than (e.g.) static type
checking but I do not agree that it is a better "sales tool". Most
people are sold based on the language and its libraries before they
start trying to install extensions.)
> If installing things is a problem, then we need to
> buckle down and finish the distutils. So, overall, I'd still vote
> against inclusion in 1.6.
So are you saying that Python 2 might have only five packages and
everything else must be downloaded? No httplib, no pickle, no random or
math, no calendar, pwd, grp, imaplib, nntplib, mailbox or rexec?
When people download Python and go to the library documentation that
impressive array of BUILT-IN-FEATURES is part of what sells them on
Python. Hell, I can download all of that stuff for Scheme but what makes
Python beautiful is that I don't have to download it for Python. It's
just there. But if an XML person comes to Python after hearing us rant
about how great it is for processing XML and all they find is
xmllib...they will be underwhelmed.
> No, it's *got* to reach 1.0. The point of the package is that it's
> exactly *one* thing to install that gives basic XML tools; you don't
> need to chase down the SAX modules from Lars' page, PyExpat from
> ftp.cwi.nl, sgmlop from pythonware.com, and so forth. If the
> Distutils made it as easy as:
> python fetchpackage.py SAX PyExpat DOM sgmlop
> <find PySAX's home site>
> <download it>
> <compile & install>
> then much of the need for a single package goes away, but, as you
> point out, that isn't currently the case.
I'm a little lost here. We need xmllib to continue because distutils
doesn't do what we need yet but we don't need to put the stuff in the
Python library because disutils will work well enough soon.
But there is an important issue that disutils will not solve. One of the
beautiful things about the Python library is that everything is at the
same version level. When you install it you know that everything works
together or else it WILL in the next patch level if you report the
incompatibility. When the xml package gets versioned incompatibly with
the Python library you don't have that safe feeling.
Paul Prescod - ISOGEN Consulting Engineer speaking for himself
Three things never trust in: That's the vendor's final bill
The promises your boss makes, and the customer's good will