From gerrit at nl.linux.org Wed Oct 1 07:23:05 2003 From: gerrit at nl.linux.org (Gerrit Holl) Date: Wed Oct 1 07:23:13 2003 Subject: [Doc-SIG] Re: [Python-Dev] Documentation packages In-Reply-To: <16249.61774.732640.328478@grendel.zope.com> References: <16249.61774.732640.328478@grendel.zope.com> Message-ID: <20031001112305.GA3667@nl.linux.org> Hi, Fred L. Drake, Jr. wrote: > After a brief discussion on the Doc-SIG, it looks like I can > reasonably drop the .tar.gz packaging for the documentation, leaving > only .zip and .tar.bz2 formats. > > Are there any strong objections to this change? What is the reason to do so? Can it do any harm do leave it in? just curious... Gerrit Holl. -- 6. If any one steal the property of a temple or of the court, he shall be put to death, and also the one who receives the stolen thing from him shall be put to death. -- 1780 BC, Hammurabi, Code of Law -- Asperger Syndroom - een persoonlijke benadering: http://people.nl.linux.org/~gerrit/ Het zijn tijden om je zelf met politiek te bemoeien: http://www.sp.nl/ From aahz at pythoncraft.com Wed Oct 1 10:02:56 2003 From: aahz at pythoncraft.com (Aahz) Date: Wed Oct 1 10:02:59 2003 Subject: [Doc-SIG] Re: [Python-Dev] Documentation packages In-Reply-To: <20031001112305.GA3667@nl.linux.org> References: <16249.61774.732640.328478@grendel.zope.com> <20031001112305.GA3667@nl.linux.org> Message-ID: <20031001140255.GA17311@panix.com> On Wed, Oct 01, 2003, Gerrit Holl wrote: > Fred L. Drake, Jr. wrote: >> >> After a brief discussion on the Doc-SIG, it looks like I can >> reasonably drop the .tar.gz packaging for the documentation, leaving >> only .zip and .tar.bz2 formats. >> >> Are there any strong objections to this change? > > What is the reason to do so? Can it do any harm do leave it in? Two points: * It's another step in the release process * It takes up extra space on the servers Following Fred's suggestion saves time and space. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "It is easier to optimize correct code than to correct optimized code." --Bill Harlan From fdrake at acm.org Wed Oct 1 14:36:15 2003 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Wed Oct 1 14:36:44 2003 Subject: [Doc-SIG] Re: [Python-Dev] Documentation packages In-Reply-To: <20031001140255.GA17311@panix.com> References: <16249.61774.732640.328478@grendel.zope.com> <20031001112305.GA3667@nl.linux.org> <20031001140255.GA17311@panix.com> Message-ID: <16251.7839.871263.562935@grendel.zope.com> Aahz writes: > * It's another step in the release process The way I wrote up the documentation release in PEP 101, generating the files isn't even a step. There are a couple of make commands that cause these to be generated; these would not change; just the definitions for those targets would change. > * It takes up extra space on the servers There is this; not a huge deal, but considering we're running on hardware owned by XS4ALL, and we're dependent on their goodwill, we shouldn't waste the space if we don't need to. > Following Fred's suggestion saves time and space. I think more important is that it reduces the number of options that get presented to some who's looking to download something. The plethora of documentation packages is almost embarassing when compared to the number of packages for the interpreter itself: the sources as a .tar.gz package (no ZIP!), and the Windows installer. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From delza at blastradius.com Wed Oct 1 16:11:36 2003 From: delza at blastradius.com (Dethe Elza) Date: Wed Oct 1 16:11:47 2003 Subject: [Doc-SIG] Re: [Python-Dev] Documentation packages In-Reply-To: <16251.7839.871263.562935@grendel.zope.com> Message-ID: <75F17D10-F44B-11D7-B481-0003939B59E8@blastradius.com> My $0.02 (Canadian), for what it's worth: While Windows users may have trouble with *.bz2, and be unfamiliar enough with the extension *.tgz to not even try (even if it does work), I've never known a *nix box to have trouble with *.zip or known a unix user who had trouble with *.zip. So I'd suggest keeping the various flavors of documentation, but standardize on zip compression. That will at least remove one variable. I agree that the main point of all of this is to reduce confusion for the newbie coming to the site to download it. But 90% of those are going to be windows users, and the rest of us have gotten used to living in a windows-dominated world. Using bz2 may get you better compression and save bandwidth, but it wasn't standard the last time I installed RedHat or Debian. Zip has it's faults, but everybody is familiar with it. --Dethe From tim at zope.com Wed Oct 1 16:18:38 2003 From: tim at zope.com (Tim Peters) Date: Wed Oct 1 16:19:46 2003 Subject: [Doc-SIG] Re: [Python-Dev] Documentation packages In-Reply-To: <75F17D10-F44B-11D7-B481-0003939B59E8@blastradius.com> Message-ID: [Dethe Elza] > While Windows users may have trouble with *.bz2, and be unfamiliar > enough with the extension *.tgz to not even try (even if it does > work), I've never known a *nix box to have trouble with *.zip or > known a unix user who had trouble with *.zip. So I'd suggest keeping > the various flavors of documentation, but standardize on zip > compression. That will at least remove one variable. A difficulty is that the HTML doc set compresses *much* better under bz2 than under zip format, and many people download over slow and expensive dialup lines. bz2 is preferred for that reason (smaller file == faster and cheaper download). > I agree that the main point of all of this is to reduce confusion for > the newbie coming to the site to download it. But 90% of those are > going to be windows users, I don't believe that, because the Windows installer for Python includes the full doc set in a Windows-friendly format. So there's simply no reason for the vast majority of Windows Python users to download the doc distribution at all. Fred, do we have stats on how often each of the files got downloaded for previous releases? > and the rest of us have gotten used to living in a windows-dominated > world. Using bz2 may get you better compression and save bandwidth, > but it wasn't standard the last time I installed RedHat or Debian. > Zip has it's faults, but everybody is familiar with it. No argument there. From tree at basistech.com Wed Oct 1 16:18:23 2003 From: tree at basistech.com (Tom Emerson) Date: Wed Oct 1 16:22:40 2003 Subject: [Doc-SIG] Re: [Python-Dev] Documentation packages In-Reply-To: <75F17D10-F44B-11D7-B481-0003939B59E8@blastradius.com> References: <16251.7839.871263.562935@grendel.zope.com> <75F17D10-F44B-11D7-B481-0003939B59E8@blastradius.com> Message-ID: <16251.13967.470512.219448@magrathea.basistech.com> Dethe Elza writes: [...] > I've never known a *nix box to have trouble with *.zip or known a unix > user who had trouble with *.zip. So I'd suggest keeping the various > flavors of documentation, but standardize on zip compression. That > will at least remove one variable. What Unix boxen do you use? I often run into Solaris, IRIX, and HP-UX boxen that lack unzip. > I agree that the main point of all of this is to reduce confusion for > the newbie coming to the site to download it. But 90% of those are > going to be windows users, and the rest of us have gotten used to > living in a windows-dominated world. Using bz2 may get you better > compression and save bandwidth, but it wasn't standard the last time I > installed RedHat or Debian. Zip has it's faults, but everybody is > familiar with it. I wouldn't switch to bz2. Even tgz can be confusing. Having .zip files for Windows users and .tar.gz files for Unix users is a happy medium that should work most everywhere. Of course for maximum Unix portability I suppose you could use .tar.Z ;-) -tree -- Tom Emerson Basis Technology Corp. Software Architect http://www.basistech.com "Beware the lollipop of mediocrity: lick it once and you suck forever" From fdrake at acm.org Wed Oct 1 16:24:15 2003 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Wed Oct 1 16:24:34 2003 Subject: [Doc-SIG] Re: [Python-Dev] Documentation packages In-Reply-To: <75F17D10-F44B-11D7-B481-0003939B59E8@blastradius.com> References: <16251.7839.871263.562935@grendel.zope.com> <75F17D10-F44B-11D7-B481-0003939B59E8@blastradius.com> Message-ID: <16251.14319.693162.119201@grendel.zope.com> Dethe Elza writes: > While Windows users may have trouble with *.bz2, and be unfamiliar > enough with the extension *.tgz to not even try (even if it does work), > I've never known a *nix box to have trouble with *.zip or known a unix > user who had trouble with *.zip. So I'd suggest keeping the various > flavors of documentation, but standardize on zip compression. That > will at least remove one variable. At this point, the bzip2 compression has been the most-requested (in terms of emails begging us to add it); the most important aspect that makes it desirable is that the file sizes are so much better. From this perspective, ZIP files are the worst for the formats which cause a lot of individual files to be packaged (most importantly, the HTML and LaTeX source formats). There are still a lot of people who want to pull the files over slow links that this seems valuable, at least for those two formats. (It may be that it's *only* valuable for those formats, and can be dropped for the PDF and PostScript formats.) > I agree that the main point of all of this is to reduce confusion for > the newbie coming to the site to download it. But 90% of those are > going to be windows users, and the rest of us have gotten used to > living in a windows-dominated world. Using bz2 may get you better > compression and save bandwidth, but it wasn't standard the last time I > installed RedHat or Debian. Zip has it's faults, but everybody is > familiar with it. Interesting; I don't recall the last time I had to build my own bzip2. I'm pretty sure I didn't do anything special to get it on RedHat recently. The bandwidth savings aren't nearly so valuable to python.org as they are to end users on metered internet connections; those are the users who were so incredibly vocal that we actually started posting those. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From barry at python.org Wed Oct 1 16:26:46 2003 From: barry at python.org (Barry Warsaw) Date: Wed Oct 1 16:26:49 2003 Subject: [Doc-SIG] Re: [Python-Dev] Documentation packages In-Reply-To: <16251.14319.693162.119201@grendel.zope.com> References: <16251.7839.871263.562935@grendel.zope.com> <75F17D10-F44B-11D7-B481-0003939B59E8@blastradius.com> <16251.14319.693162.119201@grendel.zope.com> Message-ID: <1065040005.15765.18.camel@geddy> On Wed, 2003-10-01 at 16:24, Fred L. Drake, Jr. wrote: > Interesting; I don't recall the last time I had to build my own > bzip2. I'm pretty sure I didn't do anything special to get it on > RedHat recently. No, I'm sure you didn't. bzip2 decompression should be standard on RH9, and there's even a tar option to read and write it. What I don't know is whether bz2 decompression is generally available on MacOSX... minority-platform-ly y'rs, -Barry From fred at zope.com Wed Oct 1 16:31:17 2003 From: fred at zope.com (Fred L. Drake, Jr.) Date: Wed Oct 1 16:31:29 2003 Subject: [Doc-SIG] Re: [Python-Dev] Documentation packages In-Reply-To: References: <16251.7839.871263.562935@grendel.zope.com> <75F17D10-F44B-11D7-B481-0003939B59E8@blastradius.com> <16251.13967.470512.219448@magrathea.basistech.com> Message-ID: <16251.14741.876754.348214@grendel.zope.com> Tim Peters writes: > Fred, do we have stats on how often each of the files got downloaded for > previous releases? No, but we should be able to pull those from the server logs. Maybe this weekend I'll get time to write a script to pull that data out. Tom Emerson writes: > I wouldn't switch to bz2. Even tgz can be confusing. Having .zip files > for Windows users and .tar.gz files for Unix users is a happy medium > that should work most everywhere. Interesting. bzip2 saves half a MB over gzip for the HTML and PostScript formats. What reason do you have for not using bzip2? It was very heavily requested for the file-size advantage. > Of course for maximum Unix > portability I suppose you could use .tar.Z ;-) Except nobody remembers what to do with those anymore. ;-) I haven't used compress/uncompress in *many* years. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From bac at OCF.Berkeley.EDU Wed Oct 1 20:37:46 2003 From: bac at OCF.Berkeley.EDU (Brett C.) Date: Wed Oct 1 20:38:10 2003 Subject: [Doc-SIG] Re: [Python-Dev] Documentation packages In-Reply-To: <1065040005.15765.18.camel@geddy> References: <16251.7839.871263.562935@grendel.zope.com> <75F17D10-F44B-11D7-B481-0003939B59E8@blastradius.com> <16251.14319.693162.119201@grendel.zope.com> <1065040005.15765.18.camel@geddy> Message-ID: <3F7B735A.8070401@ocf.berkeley.edu> Barry Warsaw wrote: > On Wed, 2003-10-01 at 16:24, Fred L. Drake, Jr. wrote: > > >>Interesting; I don't recall the last time I had to build my own >>bzip2. I'm pretty sure I didn't do anything special to get it on >>RedHat recently. > > > No, I'm sure you didn't. bzip2 decompression should be standard on RH9, > and there's even a tar option to read and write it. Considering RH hosts the bzip2 site I would hope you could build on their OS. =) > What I don't know > is whether bz2 decompression is generally available on MacOSX... > It is; StuffIt can decompress it. I just downloaded the GNU Info docs and had no problem with double-clicking the file and decompressing. -Brett From oussoren at cistron.nl Thu Oct 2 01:49:37 2003 From: oussoren at cistron.nl (Ronald Oussoren) Date: Thu Oct 2 01:49:48 2003 Subject: [Doc-SIG] Re: [Python-Dev] Documentation packages In-Reply-To: <1065040005.15765.18.camel@geddy> References: <16251.7839.871263.562935@grendel.zope.com> <75F17D10-F44B-11D7-B481-0003939B59E8@blastradius.com> <16251.14319.693162.119201@grendel.zope.com> <1065040005.15765.18.camel@geddy> Message-ID: <34FEA612-F49C-11D7-862D-0003931CFE24@cistron.nl> On 1 okt 2003, at 22:26, Barry Warsaw wrote: > On Wed, 2003-10-01 at 16:24, Fred L. Drake, Jr. wrote: > >> Interesting; I don't recall the last time I had to build my own >> bzip2. I'm pretty sure I didn't do anything special to get it on >> RedHat recently. > > No, I'm sure you didn't. bzip2 decompression should be standard on > RH9, > and there's even a tar option to read and write it. What I don't know > is whether bz2 decompression is generally available on MacOSX... The bzip command-line utilities are shipped as part of MacOS X. I'm not sure if Stuffit supports bzip-ed archives. Ronald From andymac at bullseye.apana.org.au Thu Oct 2 05:55:10 2003 From: andymac at bullseye.apana.org.au (Andrew MacIntyre) Date: Thu Oct 2 09:15:21 2003 Subject: [Doc-SIG] Re: [Python-Dev] Documentation packages In-Reply-To: <16251.14741.876754.348214@grendel.zope.com> References: <16251.7839.871263.562935@grendel.zope.com> <75F17D10-F44B-11D7-B481-0003939B59E8@blastradius.com> <16251.13967.470512.219448@magrathea.basistech.com> <16251.14741.876754.348214@grendel.zope.com> Message-ID: <20031002195207.S85276@bullseye.apana.org.au> On Wed, 1 Oct 2003, Fred L. Drake, Jr. wrote: > Interesting. bzip2 saves half a MB over gzip for the HTML and > PostScript formats. If you're producing PDF, why produce Postscript? AFAIK, Ghostscript digests PDF and can generate Postscript for those that have/want to use a Postscript printer. Around here, print shops seem to actually _prefer_ PDF. -- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac@bullseye.apana.org.au (pref) | Snail: PO Box 370 andymac@pcug.org.au (alt) | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia From skip at pobox.com Thu Oct 2 09:43:14 2003 From: skip at pobox.com (Skip Montanaro) Date: Thu Oct 2 09:43:25 2003 Subject: [Doc-SIG] Re: [Python-Dev] Documentation packages In-Reply-To: <75F17D10-F44B-11D7-B481-0003939B59E8@blastradius.com> References: <16251.7839.871263.562935@grendel.zope.com> <75F17D10-F44B-11D7-B481-0003939B59E8@blastradius.com> Message-ID: <16252.11122.781855.197919@montanaro.dyndns.org> Dethe> I've never known a *nix box to have trouble with *.zip or known a Dethe> unix user who had trouble with *.zip. So I'd suggest keeping the Dethe> various flavors of documentation, but standardize on zip Dethe> compression. That will at least remove one variable. Agreed. We did encounter a problem with a zip file in the SpamBayes group recently which we believe (though haven't confirmed - the OP has apparently gone underground) was related to WinZip problems. As I understand it, if you set an option in WinZip to "flatten" a zip file, all future zip files are also flattened. I guess it's a case of setting that option then poking the "Save Options" or "OK" button, then forgetting that other zip files will have structure which shouldn't be eliminated. Skip From skip at pobox.com Thu Oct 2 09:45:23 2003 From: skip at pobox.com (Skip Montanaro) Date: Thu Oct 2 09:45:32 2003 Subject: [Doc-SIG] Re: [Python-Dev] Documentation packages In-Reply-To: <1065040005.15765.18.camel@geddy> References: <16251.7839.871263.562935@grendel.zope.com> <75F17D10-F44B-11D7-B481-0003939B59E8@blastradius.com> <16251.14319.693162.119201@grendel.zope.com> <1065040005.15765.18.camel@geddy> Message-ID: <16252.11251.742634.458564@montanaro.dyndns.org> Barry> What I don't know is whether bz2 decompression is generally Barry> available on MacOSX... Fink is your friend: % type bzip2 bzip2 is /sw/bin/bzip2 so, no, it's not standard on Mac OS X. S From mwh at python.net Thu Oct 2 09:51:58 2003 From: mwh at python.net (Michael Hudson) Date: Thu Oct 2 09:51:14 2003 Subject: [Doc-SIG] Re: [Python-Dev] Documentation packages In-Reply-To: <16252.11251.742634.458564@montanaro.dyndns.org> (Skip Montanaro's message of "Thu, 2 Oct 2003 08:45:23 -0500") References: <16251.7839.871263.562935@grendel.zope.com> <75F17D10-F44B-11D7-B481-0003939B59E8@blastradius.com> <16251.14319.693162.119201@grendel.zope.com> <1065040005.15765.18.camel@geddy> <16252.11251.742634.458564@montanaro.dyndns.org> Message-ID: <2moewzzr0h.fsf@starship.python.net> Skip Montanaro writes: > Barry> What I don't know is whether bz2 decompression is generally > Barry> available on MacOSX... > > Fink is your friend: > > % type bzip2 > bzip2 is /sw/bin/bzip2 > > so, no, it's not standard on Mac OS X. Just because fink supplies something doesn't mean it didn't come with the base install. Jaguar has bzip2 installed; I don't think 10.1 did. Cheers, mwh -- SCSI is not magic. There are fundamental technical reasons why it is necessary to sacrifice a young goat to your SCSI chain now and then. -- John Woods From skip at pobox.com Thu Oct 2 09:58:10 2003 From: skip at pobox.com (Skip Montanaro) Date: Thu Oct 2 09:58:22 2003 Subject: [Doc-SIG] Re: [Python-Dev] Documentation packages In-Reply-To: <16252.11251.742634.458564@montanaro.dyndns.org> References: <16251.7839.871263.562935@grendel.zope.com> <75F17D10-F44B-11D7-B481-0003939B59E8@blastradius.com> <16251.14319.693162.119201@grendel.zope.com> <1065040005.15765.18.camel@geddy> <16252.11251.742634.458564@montanaro.dyndns.org> Message-ID: <16252.12018.287900.741829@montanaro.dyndns.org> Barry> What I don't know is whether bz2 decompression is generally Barry> available on MacOSX... Skip> Fink is your friend: Skip> % type bzip2 Skip> bzip2 is /sw/bin/bzip2 Skip> so, no, it's not standard on Mac OS X. Sorry, should have used "type -a" so I saw the version in /usr/bin. Skip From fred at zope.com Thu Oct 2 10:04:41 2003 From: fred at zope.com (Fred L. Drake, Jr.) Date: Thu Oct 2 10:04:53 2003 Subject: [Doc-SIG] Re: [Python-Dev] Documentation packages In-Reply-To: <20031002195207.S85276@bullseye.apana.org.au> References: <16251.7839.871263.562935@grendel.zope.com> <75F17D10-F44B-11D7-B481-0003939B59E8@blastradius.com> <16251.13967.470512.219448@magrathea.basistech.com> <16251.14741.876754.348214@grendel.zope.com> <20031002195207.S85276@bullseye.apana.org.au> Message-ID: <16252.12409.982231.274869@grendel.zope.com> Andrew MacIntyre writes: > If you're producing PDF, why produce Postscript? AFAIK, Ghostscript > digests PDF and can generate Postscript for those that have/want to use a > Postscript printer. Around here, print shops seem to actually _prefer_ > PDF. I recall a number of people wanting to use the PostScript to drive real PostScript printers directly. That was some time ago; perhaps Ghostscript can handle PDF sufficiently now. If there's no longer any interest in having the PostScript available, I'll be glad to drop that. I guess I really should come up with a script that pulls the relevant stats from the site logs. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From pinard at iro.umontreal.ca Thu Oct 2 11:14:24 2003 From: pinard at iro.umontreal.ca (=?iso-8859-1?Q?Fran=E7ois?= Pinard) Date: Thu Oct 2 11:14:32 2003 Subject: [Doc-SIG] Re: [Python-Dev] Documentation packages In-Reply-To: <20031002195207.S85276@bullseye.apana.org.au> References: <16251.7839.871263.562935@grendel.zope.com> <75F17D10-F44B-11D7-B481-0003939B59E8@blastradius.com> <16251.13967.470512.219448@magrathea.basistech.com> <16251.14741.876754.348214@grendel.zope.com> <20031002195207.S85276@bullseye.apana.org.au> Message-ID: <20031002151424.GA14552@alcyon.progiciels-bpi.ca> [Andrew MacIntyre] > If you're producing PDF, why produce Postscript? AFAIK, Ghostscript > digests PDF and can generate Postscript for those that have/want to use a > Postscript printer. Around here, print shops seem to actually _prefer_ > PDF. But some of us are not print shops, and have Postscript printers, which are better fed with Postscript, and do not directly accept PDF. PDF to Postscript converters are not 100% dependable, even if they do the job most of the time. Given `.pdf' and `.ps', for one, I would almost always pick the `.ps' file, to avoid possible fights and trouble. -- Fran?ois Pinard http://www.iro.umontreal.ca/~pinard From delza at blastradius.com Thu Oct 2 12:20:29 2003 From: delza at blastradius.com (Dethe Elza) Date: Thu Oct 2 12:20:36 2003 Subject: [Doc-SIG] Re: [Python-Dev] Documentation packages In-Reply-To: <16251.13967.470512.219448@magrathea.basistech.com> Message-ID: <567B7694-F4F4-11D7-8F83-0003939B59E8@blastradius.com> Tom Emerson wrote: > What Unix boxen do you use? I often run into Solaris, IRIX, and HP-UX > boxen that lack unzip. That's good feedback to have. I was only sharing my limited experience. Granted, the HP-UX boxen that I have used lacked pretty much everything, but my experiences with most forms of Unix (besides Linux and OS X) is growing quite dated now. > I wouldn't switch to bz2. Even tgz can be confusing. Having .zip files > for Windows users and .tar.gz files for Unix users is a happy medium > that should work most everywhere. Of course for maximum Unix > portability I suppose you could use .tar.Z ;-) That was more or less my point, but as Barry has pointed out, there are excellent reasons for keeping the bz2 format. Customer demand is the best reason I can think of. --Dethe From delza at blastradius.com Thu Oct 2 12:23:18 2003 From: delza at blastradius.com (Dethe Elza) Date: Thu Oct 2 12:23:27 2003 Subject: [Doc-SIG] Re: [Python-Dev] Documentation packages In-Reply-To: Message-ID: Tim Peters wrote: >> I agree that the main point of all of this is to reduce confusion for >> the newbie coming to the site to download it. But 90% of those are >> going to be windows users, > > I don't believe that, because the Windows installer for Python > includes the > full doc set in a Windows-friendly format. So there's simply no > reason for > the vast majority of Windows Python users to download the doc > distribution > at all. Ah, I didn't realize the Windows installer included the docs. Non-zip formats make a lot more sense in that case. --Dethe From cben at users.sf.net Thu Oct 2 16:09:20 2003 From: cben at users.sf.net (Beni Cherniavsky) Date: Thu Oct 2 16:09:27 2003 Subject: [Doc-SIG] Distribution formats In-Reply-To: <20030929211944.GA26915@panix.com> References: <16248.29145.25782.862817@grendel.zope.com> <20030929194932.GA18699@panix.com> <20030929211944.GA26915@panix.com> Message-ID: Aahz wrote on 2003-09-29: > On Mon, Sep 29, 2003, Beni Cherniavsky wrote: > > Aahz wrote on 2003-09-29: > >> On Mon, Sep 29, 2003, Fred L. Drake, Jr. wrote: > >>> > >>> Is there anyone currently relying on the gzipped archives who can't > >>> use the bzip2 archives? (How about the ZIP users? Can they rely on > >>> gzip or bzip2 archives?) > >> > >> WinZip (one of the standard Windows utilities) supports gzip, but I > >> can't find any sign that they support bzip2. > > > > For windows, the Free `7-Zip`__ supports them all. > > > > __ www.7-zip.org > > While that's a Good Thing, I'm not sure it addresses the issue. Should > we be in a position where in order to access material on python.org, > people have to download additional software? I think it's reasonable to > assume that people have either ZIP or bzip2, but I think that we'll get > lots of whining if we only make bzip2 available. (I'm already not > looking forward to the complaints to webmaster if we remove gzip, but > that's at least manageable.) > I agree. I just pointed it out so it can be mentioned on the site (better than nothing IMHO). IIRC (I deleted the original message) one of the things compressed in too many formats were the info files - at least for them, you can safely ignore windows users that don't know to handle bzip2 (because they surely won't know what to do with info files ;). -- Beni Cherniavsky Python - the best programming diet. From Jack.Jansen at cwi.nl Thu Oct 2 18:00:06 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Thu Oct 2 18:00:16 2003 Subject: [Doc-SIG] Re: [Python-Dev] Documentation packages In-Reply-To: <16252.11251.742634.458564@montanaro.dyndns.org> References: <16251.7839.871263.562935@grendel.zope.com> <75F17D10-F44B-11D7-B481-0003939B59E8@blastradius.com> <16251.14319.693162.119201@grendel.zope.com> <1065040005.15765.18.camel@geddy> <16252.11251.742634.458564@montanaro.dyndns.org> Message-ID: There's always machines out there that won't support newer formats out of the box, so may I suggest the following course of action: 1. For now we add bz2 compression, and put that at the top of the list, with gz far below it. If we want to get real fancy we could even put it behind another link "old formats". 2. At some point in the future we look at the http logs to see how many people still use the older format. .Z files were still very useful to some people long after .gz had become the norm, just because they were stuck on old boxes. And if Python goes out of its way to remain buildable on various old boxes as-os it would be silly if we would require people to download third-party stuff just to decode the documentation... -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From pinard at iro.umontreal.ca Thu Oct 2 20:39:41 2003 From: pinard at iro.umontreal.ca (=?iso-8859-1?Q?Fran=E7ois?= Pinard) Date: Thu Oct 2 20:39:47 2003 Subject: [Doc-SIG] Re: [Python-Dev] Documentation packages In-Reply-To: References: <16251.7839.871263.562935@grendel.zope.com> <75F17D10-F44B-11D7-B481-0003939B59E8@blastradius.com> <16251.14319.693162.119201@grendel.zope.com> <1065040005.15765.18.camel@geddy> <16252.11251.742634.458564@montanaro.dyndns.org> Message-ID: <20031003003941.GA17401@alcyon.progiciels-bpi.ca> [Jack Jansen] > .Z files were still very useful to some people long after .gz had > become the norm, just because they were stuck on old boxes. Do anybody remember `.z' files? (`pack' and `unpack' were the tools, unless I'm mistaken). I'm _not_ suggesting that they get supported :-). Despite `.Z' is not as old as `.z', they are not very far, once added some perspective. -- Fran?ois Pinard http://www.iro.umontreal.ca/~pinard From fdrake at acm.org Thu Oct 2 23:54:10 2003 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Thu Oct 2 23:54:24 2003 Subject: [Doc-SIG] Re: [Python-Dev] Documentation packages In-Reply-To: References: <16251.7839.871263.562935@grendel.zope.com> <75F17D10-F44B-11D7-B481-0003939B59E8@blastradius.com> <16251.14319.693162.119201@grendel.zope.com> <1065040005.15765.18.camel@geddy> <16252.11251.742634.458564@montanaro.dyndns.org> Message-ID: <16252.62178.436842.527925@grendel.zope.com> Jack Jansen writes: > 1. For now we add bz2 compression, and put that at the top of the > list, with gz far below it. If we want to get real fancy we > could even put it behind another link "old formats". At this point, we've been providing bzip2-compressed tarballs for three years; they became available with Python 1.6 (does anyone even remember that release?). > 2. At some point in the future we look at the http logs to see > how many people still use the older format. I'm hoping to write the script to do that this weekend. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From skip at pobox.com Thu Oct 2 09:58:10 2003 From: skip at pobox.com (Skip Montanaro) Date: Fri Oct 3 22:43:24 2003 Subject: [Doc-SIG] Re: [Python-Dev] Documentation packages In-Reply-To: <16252.11251.742634.458564@montanaro.dyndns.org> References: <16251.7839.871263.562935@grendel.zope.com> <75F17D10-F44B-11D7-B481-0003939B59E8@blastradius.com> <16251.14319.693162.119201@grendel.zope.com> <1065040005.15765.18.camel@geddy> <16252.11251.742634.458564@montanaro.dyndns.org> Message-ID: <16252.12018.287900.741829@montanaro.dyndns.org> Barry> What I don't know is whether bz2 decompression is generally Barry> available on MacOSX... Skip> Fink is your friend: Skip> % type bzip2 Skip> bzip2 is /sw/bin/bzip2 Skip> so, no, it's not standard on Mac OS X. Sorry, should have used "type -a" so I saw the version in /usr/bin. Skip _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev From dethe.elza at blastradius.com Tue Oct 7 11:54:45 2003 From: dethe.elza at blastradius.com (Dethe Elza) Date: Tue Oct 7 11:54:54 2003 Subject: [Doc-SIG] docutils issues Message-ID: <92B4C137-F8DE-11D7-A3A0-0003939B59E8@blastradius.com> Hi folks, I'm trying to build a lightweight templating system around docutils. I'm using a (slightly modified, I use core.publish_file) version of Nicola Paolucci's recipe to create an HTML fragment from a reST file, which works fine as long as there are no errors. If there are errors, I want the option of allowing the error to be processed normally (resulting in an HTML fragment with embedded error messages) or throw an exception (so I can trap it and display the text instead). I've found that if the docutils processor is running on a file, I cannot get it to throw an exception all the way out to the calling method (it traps and processes it internally), while if I use a StringIO it causes exceptions that don't show up in the file processing. Docutils appears to be using the file object as it's state machine and calling methods which aren't part of the StringIO. Finally, if I use a StringIO, I have trouble with the include directive. If I can get core.publish_file (with a real file) to optionally throw an exception on error, I think that would be all I need. Failing that I need to teach core.publish_string (or core.publish_file with StringIO "file") to optionally *not* throw an exception *and* pass it a parameter for the relative path for include directives to work. Naturally, I'd prefer the first path. TIA --Dethe From goodger at python.org Tue Oct 7 20:58:52 2003 From: goodger at python.org (David Goodger) Date: Tue Oct 7 20:59:57 2003 Subject: [Doc-SIG] docutils issues In-Reply-To: <92B4C137-F8DE-11D7-A3A0-0003939B59E8@blastradius.com> References: <92B4C137-F8DE-11D7-A3A0-0003939B59E8@blastradius.com> Message-ID: <3F83614C.5060207@python.org> Dethe Elza wrote: > I'm trying to build a lightweight templating system around docutils. ... > If there are errors, I want the option of allowing the error to be > processed normally (resulting in an HTML fragment with embedded > error messages) or throw an exception (so I can trap it and display > the text instead). Use the "--traceback" option ("traceback" setting) to allow exceptions to propagate to the calling code. The program logic for exception handling is in docutils.core.Publisher.publish(). Use "--report" and/or "--halt" options ("report_level" & "halt_level" settings) for fine control. See , "[general]" section, for details. > I've found that if the docutils processor is running on a file, I > cannot get it to throw an exception all the way out to the calling > method (it traps and processes it internally), while if I use a > StringIO it causes exceptions that don't show up in the file > processing. I suspect this may be a red herring. What Python version? There's a StringIO bug in Python 2.1 or 2.2. > Docutils appears to be using the file object as it's state machine > and calling methods which aren't part of the StringIO. Finally, if > I use a StringIO, I have trouble with the include directive. I don't follow. Please provide some supporting evidence. -- David Goodger http://starship.python.net/~goodger For hire: http://starship.python.net/~goodger/cv Docutils: http://docutils.sourceforge.net/ (includes reStructuredText: http://docutils.sf.net/rst.html) From dethe.elza at blastradius.com Fri Oct 10 14:04:24 2003 From: dethe.elza at blastradius.com (Dethe Elza) Date: Fri Oct 10 14:04:35 2003 Subject: [Doc-SIG] Docutils autonumbered lists Message-ID: <2E679E25-FB4C-11D7-A3A0-0003939B59E8@blastradius.com> Hi all, David, thanks for your reply to my last issue, we seemed to have solved it by having the requirements change underneath us... I'll try to find the place where the state machine seemed to be poking through (and dependant on file vs. StringIO). It had to do with how the include directive finds it's source directory. Of course, finding the source directory from a string (vs. a file) will be *problematic* in any case. %-) Today's issue is autonumbered lists. Since ordered lists autonumber themselves by default (in HTML), this seems like it would be easily accomplished, and I thought I remembered the notation: #. list item one #. list item two #. list item three But after trying it and going through the docs, I appear to have substituted footnote notation for list notation. Is there a clear and present reason why we don't do autonumbering for lists? What is the order of magnitude of the work needed to add it? I also wanted to share a success story. After proseletizing restructured text around the office, I finally gave up. Recently I was asked to implement a lightweight content repository and reST came up as a possible feature. So now we have a lightweight CMS with search integrated over both reST and Word documents (and our issue tracking and versioning systems), with portal-type templating, automatic reST processing, filesystem and webserver integration. It's been relatively straightforward, very successful, and now everyone in the office is learning to use reST. Thanks! --Dethe "Well I've wrestled with reality for thirty-five years now, doctor, and I'm happy to state I've finally won out over it." -- Elwood P. Dowd, Harvey From dethe.elza at blastradius.com Fri Oct 10 18:32:07 2003 From: dethe.elza at blastradius.com (Dethe Elza) Date: Fri Oct 10 18:32:19 2003 Subject: [Doc-SIG] Docutils: Line block by default Message-ID: <94D5F38E-FB71-11D7-A3A0-0003939B59E8@blastradius.com> One more docutils question. I want to set up an editing environment for my wife to organize her poetry. How would I go about processing restructured text so that it always behaves as if the line-block:: directive is in effect? TIA --Dethe "I started with nothing, and I still have most of it." -- Steven Wright From goodger at python.org Sat Oct 11 22:14:08 2003 From: goodger at python.org (David Goodger) Date: Sat Oct 11 22:14:10 2003 Subject: [Doc-SIG] Re: Docutils autonumbered lists In-Reply-To: <2E679E25-FB4C-11D7-A3A0-0003939B59E8@blastradius.com> References: <2E679E25-FB4C-11D7-A3A0-0003939B59E8@blastradius.com> Message-ID: <3F88B8F0.1080904@python.org> Dethe Elza wrote: > Today's issue is autonumbered lists. This came up recently on docutils-users. I wrote: Some thought has gone into it, and a patch for one alternative has been produced. See . > But after trying it and going through the docs, I appear to have > substituted footnote notation for list notation. I don't follow. An example is worth a lot of words. ;-) > Is there a clear and present reason why we don't do autonumbering > for lists? No clear winning syntax has presented itself. The only implementation done to date is for a candidate syntax that probably isn't a winner. The issue requires discussion and implementation. It isn't interesting enough to me to make me want to implement it myself. > What is the order of magnitude of the work needed to add it? It would require some parser work. New syntax would require new regexps. It wouldn't be a huge task, but the parser code is a bit hairy. Contributions are, as always, most welcome. > I also wanted to share a success story. After proseletizing > restructured text around the office, I finally gave up. Often new & radical ideas take a while to percolate. > It's been relatively straightforward, very successful, and now > everyone in the office is learning to use reST. > > Thanks! You're welcome. May your office experience increased efficiency through decreased reliance on Word. :-) David Goodger http://starship.python.net/~goodger For hire: http://starship.python.net/~goodger/cv Docutils: http://docutils.sourceforge.net/ (includes reStructuredText: http://docutils.sf.net/rst.html) From goodger at python.org Sat Oct 11 22:28:22 2003 From: goodger at python.org (David Goodger) Date: Sat Oct 11 22:28:23 2003 Subject: [Doc-SIG] Re: Docutils: Line block by default In-Reply-To: <94D5F38E-FB71-11D7-A3A0-0003939B59E8@blastradius.com> References: <94D5F38E-FB71-11D7-A3A0-0003939B59E8@blastradius.com> Message-ID: <3F88BC46.5080704@python.org> Dethe Elza wrote: > One more docutils question. I want to set up an editing environment > for my wife to organize her poetry. How would I go about processing > restructured text so that it always behaves as if the line-block:: > directive is in effect? Interesting question. There is no direct support for such functionality at present. You could write a script, wrapper (Docutils Reader), and/or makefile that indents the input text and prefaces it with ".. line-block::". That's the simplest and most direct solution. The "include" directive could be extended to support the "line-block" context with an option like the existing "literal" option. (In addition to a new "line-block" context, "parsed-literal" should probably also be supported. Perhaps this functionality should be generalized into a "context" option instead of multiple individual options.) A new command-line option could be added to give context. But that feels too complex. -- David Goodger http://starship.python.net/~goodger For hire: http://starship.python.net/~goodger/cv Docutils: http://docutils.sourceforge.net/ (includes reStructuredText: http://docutils.sf.net/rst.html) From dethe.elza at blastradius.com Tue Oct 14 12:51:08 2003 From: dethe.elza at blastradius.com (Dethe Elza) Date: Tue Oct 14 12:51:16 2003 Subject: [Doc-SIG] Re: Docutils autonumbered lists In-Reply-To: <3F88B8F0.1080904@python.org> Message-ID: <9BCCCFE2-FE66-11D7-985F-0003939B59E8@blastradius.com> On Saturday, October 11, 2003, at 07:14 PM, David Goodger wrote: > Dethe Elza wrote: > > Today's issue is autonumbered lists. > > This came up recently on docutils-users. I wrote: > > Some thought has gone into it, and a patch for one alternative has > been produced. See > lists>. Ah, I see. I was thinking of #2: #. Item one #. Item two or 3. Initialize first number #. Autonumber from there or a) Initialize enumeration sequence #) Autonumber from there This is how a couple of the new docutils users around the office assumed it would work, so there is something to be said for the intuitiveness of this approach. It is as close to the bullet lists of reST as possible, while still adding the extra information that enumerated lists need. > > But after trying it and going through the docs, I appear to have > > substituted footnote notation for list notation. > > I don't follow. An example is worth a lot of words. ;-) From the quickref: Autonumbered?footnotes?are possible,?like?using?[#]_?and?[#]_. ..?[#]?This?is?the?first?one. ..?[#]?This?is?the?second?one. > > Is there a clear and present reason why we don't do autonumbering > > for lists? > > No clear winning syntax has presented itself. The only implementation > done to date is for a candidate syntax that probably isn't a winner. > The issue requires discussion and implementation. It isn't > interesting enough to me to make me want to implement it myself. I guess I'll have to take a look at the patch and see if I can follow what it's doing. --Dethe "The law I sign today directs new funds and new focus to the task of collecting vital intelligence on terrorist threats and on weapons of mass production." -- George W. Bush From dethe.elza at blastradius.com Tue Oct 14 12:53:25 2003 From: dethe.elza at blastradius.com (Dethe Elza) Date: Tue Oct 14 12:53:29 2003 Subject: [Doc-SIG] Re: Docutils: Line block by default In-Reply-To: <3F88BC46.5080704@python.org> Message-ID: David Goodger wrote: > Dethe Elza wrote: > > One more docutils question. I want to set up an editing environment > > for my wife to organize her poetry. How would I go about processing > > restructured text so that it always behaves as if the line-block:: > > directive is in effect? > > Interesting question. There is no direct support for such > functionality at present. > > You could write a script, wrapper (Docutils Reader), and/or makefile > that indents the input text and prefaces it with ".. line-block::". > That's the simplest and most direct solution. OK, that sounds like a winner. I knew I could do it that way, but wasn't sure how the state-machine works. I thought maybe I could initialize it in such a way that the line-block directive appeared to already be in effect. --Dethe "Trusting a scientist on questions of metaphysics is like paying someone else to worship God for you." -- Bill Welton From goodger at python.org Fri Oct 17 11:08:01 2003 From: goodger at python.org (David Goodger) Date: Fri Oct 17 11:08:07 2003 Subject: [Doc-SIG] Re: Docutils autonumbered lists In-Reply-To: <9BCCCFE2-FE66-11D7-985F-0003939B59E8@blastradius.com> References: <9BCCCFE2-FE66-11D7-985F-0003939B59E8@blastradius.com> Message-ID: <3F9005D1.6030607@python.org> Dethe Elza wrote: > I'll try to find the place where the state machine seemed to be > poking through (and dependant on file vs. StringIO). It had to do > with how the include directive finds it's source directory. Please be sure you're using the latest Docutils code from CVS. ISTR that a relevant bug was fixed recently. > Of course, finding the source directory from a string (vs. a file) > will be *problematic* in any case. %-) Very true. I think the best way to proceed is to use the current working directory as a base for relative paths. If "include" doesn't already do that, please open a bug report. -- David Goodger http://starship.python.net/~goodger For hire: http://starship.python.net/~goodger/cv Docutils: http://docutils.sourceforge.net/ (includes reStructuredText: http://docutils.sf.net/rst.html)