Re: [XML-SIG] Developer's Day
"Andrew M. Kuchling" wrote:
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?
I don't understand this issue. Why would a C extension build on sgmlop which is designed to make XML information available to *Python* programmers?
* 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 together.
(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.)
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.
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 http://www.geezjan.org/humor/computers/threes.html
(Responding to the python-dev related portion of this...) Paul Prescod writes:
No, no; I'm arguing against shipping with Expat; sgmlop good! Consider this scenario: * Python includes Expat 1.0 * Some C library (for DAV or whatever) uses Expat 1.1 * Someone writes a Python interface to this C library and attempts to compile it statically. * Two versions of Expat in the same binary; symbol conflicts and core dumps, oh my!
I'm not arguing for dropping existing packages; I'm against adding many more of them. Existing library modules can stay where they are. But I wouldn't mind a minimalist Python too much, if it came with a script fetch-basic-packages: python fetch-packages.py httplib python fetch-packages.py imaplib ... 200 more lines ...
Basically, yes. -- A.M. Kuchling http://starship.python.net/crew/amk/ And now let us hasten to the station. I have commanded the rain to fall at exactly one-fifteen and I would hate to get my shoes wet. -- Lord Lavender, in SEBASTIAN O #2
On Thu, 16 Dec 1999, Andrew M. Kuchling wrote:
We should ship pyexpat, not Expat. (IMO)
Considering that it would probably use HTTP to fetch the packages, I think you wouldn't be fetching httplib :-) But yes: I agree with the basic sentiment. Cheers, -g -- Greg Stein, http://www.lyra.org/
Paul Prescod wrote: [...]
(Nodding in agreement) Could this perhaps be solved with a large batteries-included standard distribution, plus a real easy/effective way to strip Python down and wrap things up for deployment? In other words, aim for two very distinct goals: everything within easy reach for development + fully signed-sealed-delivered products. The first goal can evolve to do fancy net-bourne distribution, even if it is a brittle process, because this is for Python developers. They want it all, so open the floodgate to give it all to them. The second becomes a matter or pruning down and wrapping up. All the way down to an single installation-less executable, if possible. I may well be wrong (and I'm not tracking distutils), but might it not be simpler to focus on 1) power users + 2) production-grade deployment, instead of trying to streamline a tangled-web-of-module-dependencies into a distribution system which tries to meet a wide range of needs?
More nods. So why not allow the Python distribution to become very large - with every release moving to a better-tuned combination of all the different parts (occasional mishaps can quickly be fixed)? Plus some tools to dist(ut)il(l) a turnkey solution from this big soup. Sort-of-from-violin-to-quartet-all-the-way-to-symphony-orchestra... -- Jean-Claude
(Responding to the python-dev related portion of this...) Paul Prescod writes:
No, no; I'm arguing against shipping with Expat; sgmlop good! Consider this scenario: * Python includes Expat 1.0 * Some C library (for DAV or whatever) uses Expat 1.1 * Someone writes a Python interface to this C library and attempts to compile it statically. * Two versions of Expat in the same binary; symbol conflicts and core dumps, oh my!
I'm not arguing for dropping existing packages; I'm against adding many more of them. Existing library modules can stay where they are. But I wouldn't mind a minimalist Python too much, if it came with a script fetch-basic-packages: python fetch-packages.py httplib python fetch-packages.py imaplib ... 200 more lines ...
Basically, yes. -- A.M. Kuchling http://starship.python.net/crew/amk/ And now let us hasten to the station. I have commanded the rain to fall at exactly one-fifteen and I would hate to get my shoes wet. -- Lord Lavender, in SEBASTIAN O #2
On Thu, 16 Dec 1999, Andrew M. Kuchling wrote:
We should ship pyexpat, not Expat. (IMO)
Considering that it would probably use HTTP to fetch the packages, I think you wouldn't be fetching httplib :-) But yes: I agree with the basic sentiment. Cheers, -g -- Greg Stein, http://www.lyra.org/
Paul Prescod wrote: [...]
(Nodding in agreement) Could this perhaps be solved with a large batteries-included standard distribution, plus a real easy/effective way to strip Python down and wrap things up for deployment? In other words, aim for two very distinct goals: everything within easy reach for development + fully signed-sealed-delivered products. The first goal can evolve to do fancy net-bourne distribution, even if it is a brittle process, because this is for Python developers. They want it all, so open the floodgate to give it all to them. The second becomes a matter or pruning down and wrapping up. All the way down to an single installation-less executable, if possible. I may well be wrong (and I'm not tracking distutils), but might it not be simpler to focus on 1) power users + 2) production-grade deployment, instead of trying to streamline a tangled-web-of-module-dependencies into a distribution system which tries to meet a wide range of needs?
More nods. So why not allow the Python distribution to become very large - with every release moving to a better-tuned combination of all the different parts (occasional mishaps can quickly be fixed)? Plus some tools to dist(ut)il(l) a turnkey solution from this big soup. Sort-of-from-violin-to-quartet-all-the-way-to-symphony-orchestra... -- Jean-Claude
participants (4)
-
Andrew M. Kuchling -
Greg Stein -
Jean-Claude Wippler -
Paul Prescod