On Tue, 11 Feb 2003 12:40 pm, Guido van Rossum wrote: > No PEP is needed, but I'd like to understand more of the mechanics of > adding this to the distribution. I've got no problem with adding more > Python code to the standard library, but (as Brett mentioned) I'd like > to keep the kjbuckets C code out unless we have a volunteer to both > clean it up and maintain it. The C code will go away soon, thanks to Anthony's efforts in the kjbuckets python module (the conversion to the new sets implementation, amongst other enhacements). > Also, I just looked at the copy of gadfly that's part of Zope, and it > is about 15,000 lines! (And that's only Python code -- no C code > included, nor docs.) Do we really need all that? The cleaned up version in the sourceforge project is 11k. We may be able to remove the 1.2kloc parser builder. > Who is going to maintain it? I have no answer for this. The sourceforge project has a number of maintainers, but there are old outstanding bugs which have had no attention (some even have patches). I'm afraid it's at the bottom of my priority list at present. > Is somebody going to convert the gadfly docs (assuming > they exist) into LaTeX? I converted them to ReST as part of my cleanup, so a docutils writer which writes the python doc LaTeX format _should_ be possible (it'd be a nice-to-have for Python documentation regardless :) > Or is it just going to be an undocumented > pile of code that only people who happen to already know how to use it > can really use? It is documented already. Stuart is looking at implemeting the DB-API 2.0 interface for it, so the doc will need updating at that point. That's not a mammoth task though. Richard
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4