Martin v. Lwis wrote:
As for PEP 4: I don't know whether it needs to be listed there. It
appears that the PEP is largely unmaintained (I, personally, do not
really maintain it). So one option would be to just stop using PEP 4
for recording deprecations, since we now have the warnings module.
If we
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
Raymond Hettinger wrote:
* Deprecated modules just get moved to the lib-old directory. If
someone has ancient code relying on the module, it is a somewhat trivial
maintenance step to add lib-old to their PYTHONPATH. IOW, I fail to see
the harm.
I have never considered this as an official policy.