From mwh at python.net Fri Sep 3 13:10:59 2004 From: mwh at python.net (Michael Hudson) Date: Fri Sep 3 13:11:02 2004 Subject: [Doc-SIG] partial rewrite of the "extending and embedding" manual In-Reply-To: <200408101237.57748.fdrake@acm.org> (Fred L. Drake, Jr.'s message of "Tue, 10 Aug 2004 12:37:57 -0400") References: <2mzn572dl4.fsf@starship.python.net> <2m3c2v0ziq.fsf@starship.python.net> <200408101237.57748.fdrake@acm.org> Message-ID: <2my8jr38vw.fsf@starship.python.net> "Fred L. Drake, Jr." writes: > On Tuesday 10 August 2004 11:43 am, Michael Hudson wrote: > > Noone? Oh well... > > I'm not ignoring you, just way too busy right now. Feel free to > remind me a couple of weeks if you haven't heard anything from me. OK :-) I've just uploaded a new version to: http://starship.python.net/crew/mwh/toext/ While not wanting to disparage in any way those few brave souls who've beta tested this, I'd still like more feedback! I realize this isn't an incredibly important thing, but I do think the current Ext & Emb manual is in a pretty parlous state. I'd like the finished version of my document to replace it, /maybe/ for 2.4 final if I really get typing, but by 2.5 at the latest. I also seem to have accumulated these wishes along the way: a way to link to files, like \verbatiminput, but NOT including the contents of the file would be nice (for setup.py files). a way to turn each mention of an API function into a link to its documentation in the API reference would be *really* nice (this sounds hard! parsing api.idx? brr!). I surprise myself, but I think I'd like to see a javadocesque approach to the API reference: associating each API function very closely with its documentation in the source, and then maybe having a variety of ways of arranging the results (e.g. by category (very high level interface, abstract interface, concrete interface, ...) or alphabetically). Cheers, mwh -- "Sturgeon's Law (90% of everything is crap) applies to Usenet." "Nothing guarantees that the 10% isn't crap, too." -- Gene Spafford's Axiom #2 of Usenet, and a corollary From amk at amk.ca Fri Sep 10 20:19:59 2004 From: amk at amk.ca (A.M. Kuchling) Date: Fri Sep 10 20:20:27 2004 Subject: [Doc-SIG] Annotatable copy of Python docs Message-ID: <20040910181959.GB17625@rogue.amk.ca> As an experiment, I've paired the HTML version of the 2.3.4 docs with a Wiki thanks to frames and some JavaScript. The starting point is at http://pydoc.amk.ca/frame.html . Feel free to add commentary, links, or other material to the Wiki. If people actually use it, it'll get moved to python.org. --amk From fdrake at acm.org Fri Sep 17 19:09:47 2004 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Fri Sep 17 19:10:03 2004 Subject: [Doc-SIG] Planning to drop gzip compression for future releases. Message-ID: <200409171309.48011.fdrake@acm.org> At this point, I'm planning to drop the gzip-compressed archives for all future Python releases. The bzip2 archives are much smaller (saving bandwidth, disk space, and download time), and supporting software seems to have become widely available in both free and commercial tools. I'm still planning to make ZIP archives available. If anyone would like to argue that I should drop that as well, feel free. ;-) -Fred -- Fred L. Drake, Jr. From fdrake at acm.org Tue Sep 21 16:36:15 2004 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Tue Sep 21 16:36:35 2004 Subject: [Doc-SIG] Re: [Python-Dev] Planning to drop gzip compression for future releases. In-Reply-To: <414E3B09.9070407@interlink.com.au> References: <200409171309.48011.fdrake@acm.org> <91489DBB-08FC-11D9-A518-000D932927FE@opnet.com> <414E3B09.9070407@interlink.com.au> Message-ID: <200409211036.15861.fdrake@acm.org> [Responding to an absolutely enormous deluge of emails on python-dev...] On Sunday 19 September 2004 10:06 pm, Anthony Baxter wrote: > I have no intention of dropping tar.gz source releases. I think Fred > was talking about the documentation tarballs. Even then, I think there's > some advantages to keeping both, and I don't really see the advantage > to dropping the tar.gz format. But hey, that's up to Fred - he's the > one who makes the doc releases. Dang, it doesn't pay to be away from email for three days, does it? Yes, I was only talking about documentation releases. It never occurred to me anyone would think I was talking about Python source releases. Maybe I shouldn't have added python-dev to the recipients list for my original email, but too often objections get heard quite late if I don't include python-dev. For the documentation, there's a much longer history of providing the bz2 versions of the archives. There are also many more archives we can drop per release. While in theory disk space isn't supposed to be an issue, it seems to be something our sysadmin group is dealing with on a regular basis (mostly cleaning up old webserver logs). So while the space itself may not be an issue, it certainly generates tedious work for volunteers. My motivation in dropping the bz2 archives is two-fold: 1. Reduce disk space consumed per release, mostly to ease the burden on the sysadmin group. 2. Reduce the number of files posted for the documentation per release, so that choices for end-users are easier to pick through. -Fred -- Fred L. Drake, Jr. From fdrake at acm.org Tue Sep 21 17:07:02 2004 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Tue Sep 21 17:07:31 2004 Subject: [Doc-SIG] Re: [Python-Dev] Planning to drop gzip compression for future releases. In-Reply-To: <200409211036.15861.fdrake@acm.org> References: <200409171309.48011.fdrake@acm.org> <414E3B09.9070407@interlink.com.au> <200409211036.15861.fdrake@acm.org> Message-ID: <200409211107.02590.fdrake@acm.org> This morning, I wrote: > My motivation in dropping the bz2 archives is two-fold: That should be the *gz* archives, not the bz2 archives! -Fred -- Fred L. Drake, Jr.