Martin v. Löwis wrote:
Brett C. wrote:
I noticed that Makefile.pre.in uses the value from the environment
variable LDFLAGS but not CPPFLAGS. Any reason for this?
How did you notice that? For LDFLAGS, Makefile.pre.in has
LDFLAGS=@LDFLAGS@
This does *not* mean that the value from the
Brett C. wrote:
I realize that much. But if you look in configure.in it seems to use
the previous value of LDFLAGS every time it is redefined as a base and
thus gets its initial value from the environment variable the first time
it is tweaked.
Yes, it would be possible to do the same thing for
On Mon, 2004-12-06 at 16:28, Martin v. Löwis wrote:
Martin, +1 on everything you wrote, with one minor quibble.
Removal
===
If the module has been deprecated for atleast a year and atleast
a version, it can be removed. Removal should move it to old-libs
for pure Python modules; a
On Sun, 2004-12-05 at 18:54 +0100, Martin v. Löwis wrote:
I think it would be better to *remove* the xmllib documentation.
Existing code which needs the module will continue to work even
without documentation, and new code is unlikely to be written for
a module that has no documentation, and
* The average quality of the library improves as we take out junk (the
tzparse module for example) and put in high quality modules like
logging, csv, decimal, etc.
Yes and no. The added modules have to be relevant to what users want
to do. While (relatively) minor stuff like csv and decimal
Statements like this are pretty common, but there's no evidence (that I've
ever seen pointed to) that someone has *measured* how many people want
modules for X.
I almost didn't send this in, because I figured someone would have to
argue with it.
If there are that many people that want (e.g.)
As far as I can tell, there are no CSS or XML 1.1 parsers for
Python, period.
This belongs on c.l.p, I suppose, but the first page of google results
includes:
http://www.python.org/pypi?:action=displayname=TG%20CSS%20Toolsversion=1.
0a1
http://cthedot.de/cssutils/
=Tony.Meyer
