From tvalusek@vs.inext.cz Sat Mar 1 02:08:56 1997 From: tvalusek@vs.inext.cz (Tomas Valusek) Date: Sat, 1 Mar 1997 02:08:56 +-100 Subject: [PYTHON DOC-SIG] Needed Python docs in RTF format Message-ID: <01BC25E5.861B3600@asvs06.inext.cz> Please help me get started with Python. Because of my weak eyes, I have = trouble reading PDF docs, and Winhelp files are hard to read because = some entries (especially contents entries with added text) are hard to = acces using WinHelp95 Contents tab. I need to change font size for best = reading to ca. 14 pts. I am using Pythonwin with Win95. Thank you. Tom Valusek _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From fdrake@CNRI.Reston.Va.US Sat Mar 1 05:01:16 1997 From: fdrake@CNRI.Reston.Va.US (Fred L. Drake) Date: Sat, 1 Mar 1997 00:01:16 -0500 (EST) Subject: [PYTHON DOC-SIG] New ni style example. In-Reply-To: <199702282300.KAA10365@minotaur.labyrinth.net.au> from "Mark Hammond" at Mar 1, 97 09:56:19 am Message-ID: <199703010501.AAA04415@weyr.CNRI.Reston.Va.US> Mark Hammond wrote: > And another Microsoft-centric rant, which I'd like to pass by you > all. Microsoft is moving its entire help system to HTML!!! It is > doing this in 2 ways: > * By adding special keyword and indexing tags to the HTML standard, > and submitting them for approval. Apparently, the relevant body > modified it, renamed it, and ratified it. > * By designing yet another something-or-other which allows many HTML > files to be concatenated into some sort of container, including I > think compression. They will then submit this to whoever does this Mark, I'd like to know where to find more specific information on the proposals; are they public in any way? It sounds like a bad idea to me, primarily because HTML just isn't strong enough for this kind of thing. The HTML version should be generated from a more appropriate format. -Fred -- Fred L. Drake, Jr. fdrake@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive Reston, VA 20191-5434 _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From MHammond@skippinet.com.au Mon Mar 3 00:45:53 1997 From: MHammond@skippinet.com.au (Mark Hammond) Date: Mon, 3 Mar 1997 10:45:53 +1000 Subject: [PYTHON DOC-SIG] New ni style example. Message-ID: <199703022350.KAA25821@minotaur.labyrinth.net.au> > I'd like to know where to find more specific information on the > proposals; are they public in any way? It sounds like a bad idea to I saw it in a 5 line PC Week (Aust) article, so it sisnt say much. It did say the MS' first proposal, and the modified ratified one, are not compatible, so Microsoft are holding off on a public beta until their tools support the raitified version. But it is very close. Their Web site may have info, but I have looked for it. > me, primarily because HTML just isn't strong enough for this kind of > thing. The HTML version should be generated from a more appropriate > format. I must admit to having the same thoughts, and MS pretty much _do_ have the technology to do this now! But then again, the only real problems I saw wrt moving from "winhelp" to "help" where these exact issues. It really isnt as if their existing toolset (ie, WinHelp) is anything that flash in itself. So while not a great step forward for them, it certainly wouldnt be backwards, and gives their marketting people something to play with (ie, they will tell you how they embrace Web standards by using HTML, but will surely neglect to mention that only their tools know about the format :-) Mark. ---------------------------------------------------------------------- Mark Hammond - MHammond@skippinet.com.au Check out Python - _the_ language for the Web/CGI/Windows/MFC/Unix/etc & _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From MHammond@skippinet.com.au Mon Mar 3 00:45:53 1997 From: MHammond@skippinet.com.au (Mark Hammond) Date: Mon, 3 Mar 1997 10:45:53 +1000 Subject: [PYTHON DOC-SIG] Needed Python docs in RTF format Message-ID: <199703022350.KAA25845@minotaur.labyrinth.net.au> > Please help me get started with Python. Because of my weak eyes, I > have trouble reading PDF docs, and Winhelp files are hard to read > because some entries (especially contents entries with added text > are hard to acces using WinHelp95 Contents tab. I need to change > font size for best reading to ca. 14 pts. I am using Pythonwin with > Win95. Have you checked out all the Win95 options for this sort of thing? You may find you can adjust winhelp to a more suitable size. However, I admit to not knowing much about these options. I have the Python documents in RTF, but not a "general" RTF - only as the input for "WinHelp" which is not really setup for reading. What about grabbing the .HTML versions, and either configuring your browser of choice to use the big fonts? Thats the easiest I can come up with. Or else hack the postscript to create larger fonts, and then use some postscript viewer/printer. I know almost nothing about this route, but I imagine its not too difficult Mark. ---------------------------------------------------------------------- Mark Hammond - MHammond@skippinet.com.au Check out Python - _the_ language for the Web/CGI/Windows/MFC/Unix/etc & _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From tvalusek@vs.inext.cz Mon Mar 3 01:14:34 1997 From: tvalusek@vs.inext.cz (Tomas Valusek) Date: Mon, 3 Mar 1997 01:14:34 +-100 Subject: [PYTHON DOC-SIG] Needed Python docs in RTF format Message-ID: <01BC2770.422877A0@asvs01.inext.cz> Have you checked out all the Win95 options for this sort of thing? =20 You may find you can adjust winhelp to a more suitable size. =20 However, I admit to not knowing much about these options. Of course I use the maximum available font size in WinHelp, but WinHelp = version is rather buggy, because some articles are not accesible from = "contents" tab (they appear there as books) and accesed via "Index" = WinHelp pops up window saying something about wrong window name (but = after hitting OK the text appears). Another problem is that I hate = WinHelp's behaviour to print each topic on separate page. I also cannot = affect the font size on written output. What about grabbing the .HTML versions, and either configuring your=20 browser of choice to use the big fonts? Thats the easiest I can come=20 up with. Do you know about FREE (non-shareware) Web site grabber? There are some = available comercially, but they are rather expensive for me. Tom Valusek _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From fredrik_lundh@ivab.se Mon Mar 3 00:21:31 1997 From: fredrik_lundh@ivab.se (Fredrik Lundh) Date: Mon, 3 Mar 1997 01:21:31 +0100 Subject: [PYTHON DOC-SIG] Needed Python docs in RTF format In-Reply-To: <01BC2770.422877A0@asvs01.inext.cz> (tvalusek@vs.inext.cz) Message-ID: <9703030021.AA28586@arnold.image.ivab.se> > > What about grabbing the .HTML versions, and either configuring your > > browser of choice to use the big fonts? Thats the easiest I can come > > up with. > > Do you know about FREE (non-shareware) Web site grabber? There are some > available comercially, but they are rather expensive for me. FYI, the standard Python docs are available in HTML and other formats via: http://www.python.org/ftp/python/doc/ As for grabbing web sites, I think someone (Guido?) once posted a "robot" script. Could be an idea to check the locator: http://www.python.org/locator Cheers /F _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From tvalusek@vs.inext.cz Mon Mar 3 02:17:07 1997 From: tvalusek@vs.inext.cz (Tomas Valusek) Date: Mon, 3 Mar 1997 02:17:07 +-100 Subject: [PYTHON DOC-SIG] Grabbing HTML version docs in one step Message-ID: <01BC2779.001A9740@asvs01.inext.cz> As for grabbing web sites, I think someone (Guido?) once posted a "robot" script. Could be an idea to check the locator: http://www.python.org/locator Cheers /F I looked there but I'm confused. Thanks for advice, anyway. Tom Valusek _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From guido@CNRI.Reston.Va.US Mon Mar 3 02:41:06 1997 From: guido@CNRI.Reston.Va.US (Guido van Rossum) Date: Sun, 02 Mar 1997 21:41:06 -0500 Subject: [PYTHON DOC-SIG] Needed Python docs in RTF format In-Reply-To: Your message of "Mon, 03 Mar 1997 01:21:31 +0100." <9703030021.AA28586@arnold.image.ivab.se> References: <9703030021.AA28586@arnold.image.ivab.se> Message-ID: <199703030241.VAA04592@monty> > FYI, the standard Python docs are available in HTML and other formats > via: > > http://www.python.org/ftp/python/doc/ > > As for grabbing web sites, I think someone (Guido?) once posted a > "robot" script. Could be an idea to check the locator: > > http://www.python.org/locator I recently posted a "webchecker" script which is not quite a web grabber. It is also on ftp.python.org in /pub/tmp (until I find a better place for it). It should be straightforward to turn this into a grabber. Much longer ago I posted a "robot" thingie for the same purpose that is better forgotten. I believe I saw a post from someone else who had turned it into a grabber, recently. --Guido van Rossum (home page: http://www.python.org/~guido/) _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From tismer@tismer.com Mon Mar 3 14:46:44 1997 From: tismer@tismer.com (Christian Tismer) Date: Mon, 03 Mar 1997 15:46:44 +0100 Subject: [PYTHON DOC-SIG] Needed Python docs in RTF format References: <9703030021.AA28586@arnold.image.ivab.se> <199703030241.VAA04592@monty> Message-ID: <331AE454.25B2@tismer.com> > I recently posted a "webchecker" script which is not quite a web > grabber. It is also on ftp.python.org in /pub/tmp (until I find a > better place for it). It should be straightforward to turn this into > a grabber. A similar but even easier solution is (and I did it :) : Use Guido's /tools/scripts/ftpmirror.py on the appropriate directory of ftp.python.org, since the whole site is accessible through FTP. If you just want to grab HTML and use a fresh directory it works immediately. There is a minor NT/W95 related bug with binary files and the rename function. I'd just let it grab the whole ftp://ftp.python.org/pub/www.python.org/doc/ > > Much longer ago I posted a "robot" thingie for the same purpose that > is better forgotten. I believe I saw a post from someone else who had > turned it into a grabber, recently. But ftpmirror is still alive, isn't it? Sorry, I was nearly ready with the last patches for the NT problems, firewall traversal and that stuff, but by testing it I wrote it over with the old version (yes, like a greenhorn), so it make take some time until I'll want to write it again :-/ BTW, to the makers of FTPlib: It is not fire proof. There are circumstances where it will hang, or report a wrong error. I tested it with a WinGate beta which gave incomplete messages partially. Someone should enhance the error handling. (in the hope you don't suggest me..:) - chris _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From Barry A. Warsaw" Message-ID: <199703031616.LAA03490@anthem.CNRI.Reston.Va.US> >>>>> "MH" == Mark Hammond writes: MH> Couple of quick questions - how can a ni package provide doc MH> strings? Eg, a package named "xyz" is a directory, _not_ a MH> file. I added a convention to gendoc that a file called MH> "__doc__" in a packages directory will be read, and treated as MH> docstrings for the module itself (which makes lots of sense to MH> me, as then you dont need to distribute it) Also, I "flatten" MH> the "__init__" module, so that all docstrings and methods are MH> documented in the package itself - ie, __init__ never gets a MH> mention in the docs. Do these sound OK? I think Ken M. was the first to champion flatting of __init__ into the package module. The argument is that flattening is the most natural way to think about package modules and most package authors are going to want to this, so it makes sense to be the default behavior. I even went so far as to add the couple of lines to ni.py to make this happen, but Guido nixed it, partially because there wasn't enough experience with ni.py to back-up the `most common usage' argument. In any case, when I packagized some parts of Grail, I added the following gross hack (taken from fonts/__init__.py): -------------------- snip snip -------------------- def font_from_name(psfontname): # ... # the general solution... gross! for name in ['font_from_name', '__doc__']: setattr(__, name, vars()[name]) -------------------- snip snip -------------------- So I place the one __init__.py function, and __init__'s __doc__ into the package. I think this makes more sense than using a __doc__.py file since I personally can't see any reason why __init__.py's docstring wouldn't be the package's docstring. What I would to do ni, is automatically put any non-underscore prefixed symbol appearing in __init__.py into the package module's namespace. I would also put __doc__ into that namespace. It's all of a two or three line change to ni.py. Also, you might provide some way of controlling what gets put into the package's namespace from __init__.py. -Barry _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From MHammond@skippinet.com.au Tue Mar 4 22:49:25 1997 From: MHammond@skippinet.com.au (Mark Hammond) Date: Wed, 5 Mar 1997 08:49:25 +1000 Subject: [PYTHON DOC-SIG] Templatising gendoc, and more. Message-ID: <199703042153.IAA21222@minotaur.labyrinth.net.au> > Date: Mon, 3 Mar 1997 11:16:34 -0500 > From: "Barry A. Warsaw" > To: MHammond@skippinet.com.au > Cc: doc-sig@python.org > Subject: Re: [PYTHON DOC-SIG] Templatising gendoc, and more. > Reply-to: "Barry A. Warsaw" > > >>>>> "MH" == Mark Hammond writes: > > MH> Couple of quick questions - how can a ni package provide doc > MH> strings? Eg, a package named "xyz" is a directory, _not_ a > MH> file. I added a convention to gendoc that a file called > MH> "__doc__" in a packages directory will be read, and treated as > MH> docstrings for the module itself (which makes lots of sense to > MH> me, as then you dont need to distribute it) Also, I "flatten" > MH> the "__init__" module, so that all docstrings and methods are > MH> documented in the package itself - ie, __init__ never gets a > MH> mention in the docs. Do these sound OK? > > I think Ken M. was the first to champion flatting of __init__ into the > package module. The argument is that flattening is the most natural > way to think about package modules and most package authors are going > to want to this, so it makes sense to be the default behavior. I even > went so far as to add the couple of lines to ni.py to make this > happen, but Guido nixed it, partially because there wasn't enough > experience with ni.py to back-up the `most common usage' argument. > > In any case, when I packagized some parts of Grail, I added the > following gross hack (taken from fonts/__init__.py): :-) Ive come up with the same hacks, without ever seeing fonts :-) Ive _always_ done this in __init__, and maybe we would find that the "most common usage" argument is more pervasive now? > What I would to do ni, is automatically put any non-underscore > prefixed symbol appearing in __init__.py into the package module's > namespace. I would also put __doc__ into that namespace. It's all of > a two or three line change to ni.py. Also, you might provide some way > of controlling what gets put into the package's namespace from > __init__.py. Im sure many people will dis-agree here, but IMO docstrings in the code is cute, but on-line browsing of docstrings wont be used anywhere near as much as generated documentation. I think it most important docstrings be kept near the sources for maintenance, rather than browsing. I'd ask if flattening of the doc strings at run-time is really worth it? Another interesting "feature" of docstrings is that the sources often get _twice_ as big (Python is partly to blame here, as the programs themselves are often so small :-). If you consider the win32com stuff, not only are the sources twice as big, all the doc strings are _also_ in the generated HTML. And at run-time, obviously, they take more memory. And the more keen you are with the documentation, the more penalty you pay. (OK - were not talking too much, and Im not really _that_ concerned, but...) This is one reason why I like my new little __doc__ file convention. It means I can put "overview" type information in a seperate file that is included in the HTML build, but not part of the sources (but still very close). Browsers wont see it, but people browsing wont be looking for "overview" information anyway - they are more likely to be looking for a specific object... Mark. ---------------------------------------------------------------------- Mark Hammond - MHammond@skippinet.com.au Check out Python - _the_ language for the Web/CGI/Windows/MFC/Unix/etc & _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From Barry A. Warsaw" Message-ID: <199703042206.RAA20200@anthem.CNRI.Reston.Va.US> >>>>> "MH" == Mark Hammond writes: MH> Ive _always_ done this in __init__, and maybe we would find MH> that the "most common usage" argument is more pervasive now? Indeed! MH> Im sure many people will dis-agree here, but IMO docstrings in MH> the code is cute, but on-line browsing of docstrings wont be MH> used anywhere near as much as generated documentation. As opposed to Emacs Lisp docstrings, which is my first model for how this stuff can be used. There are many differences b/w Elisp docstrings and Python docstring, but there are some similarities (sorry for quoting out of order): MH> Another interesting "feature" of docstrings is that the MH> sources often get _twice_ as big Elisp byte-compiled files suffer the same fate, which I why I only docstring-ify functions intended as part of the public interface to a package. Otherwise, I use comments instead of docstrings (although the actual content is very similar), or sometimes just don't include text in that place in the code. MH> I think it most important docstrings be kept near the sources MH> for maintenance, rather than browsing. I'd ask if flattening MH> of the doc strings at run-time is really worth it? I was probably not clear (or I'm misunderstanding). I only put sort-of meta-package documentation in __init__.py's docstring, and I think it makes sense to flatten that into the package module's namespace, since you are documenting the package. But I agree that on-line browsing of the docstrings will probably never be very widespread, until we get Pymacs/PTUI to replace all of Our Favorite Editors. :-) -Barry _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From tvalusek@vs.inext.cz Wed Mar 5 23:38:59 1997 From: tvalusek@vs.inext.cz (Tomas Valusek) Date: Wed, 5 Mar 1997 23:38:59 +-100 Subject: [PYTHON DOC-SIG] Bugs in documentation Message-ID: <01BC29BE.67987120@asvs01.inext.cz> Hi, I'm making a slow progress in reading docs, but I've found some bugs already. General bug: In Library Reference, Chapter 2.1.4 are swapped descriptions of / and % operators. Quite fatal for unexperienced ... HTML downloadable docs: ../icons directory referred in files is not included in .tar.gz package. Tom Valusek _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From richard.jones@bom.gov.au Thu Mar 6 18:39:21 1997 From: richard.jones@bom.gov.au (Richard Jones) Date: Thu, 06 Mar 1997 13:39:21 EST Subject: [PYTHON DOC-SIG] _using_ gendoc Message-ID: <199703060343.WAA21522@python.org> OK, I'm confused. I needed a nicely readable version of the SocketServer documentation, so I thought I'd give gendoc a bash. Well, after getting strange errors (below) in import mode (sorry, I really don't have time to delve into the source), I tried the parsing mode. I got a result, but _none_ of the embedded doc strings made it through... So I tried running gendoc over itself (gendoc.py) and again, no docstrings - either in import mode or in parse mode! Can anyone shed any light on my inability to use gendoc correctly? Please? :) Richard > gendoc -d ../documentation /usr/local/lib/python/SocketServer.py Traceback (innermost last): File "/usr/local/bin/gendoc", line 5, in ? gendoc.gendoc.main() File "/usr/local/lib/python/gendoc/gendoc.py", line 228, in main manpages = collect(args, formats, head) File "/usr/local/lib/python/gendoc/gendoc.py", line 270, in import_collect manpages = doc_collect.gendoc(doc_collect.doc_collect(modules)) File "/usr/local/lib/python/gendoc/doc_collect.py", line 685, in doc_collect return map(collector, module_list) File "/usr/local/lib/python/gendoc/doc_collect.py", line 664, in collector col.collect() File "/usr/local/lib/python/gendoc/doc_collect.py", line 533, in collect elif type(value) == ClassType and \ TypeError: not enough arguments _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From klm@CNRI.Reston.Va.US Thu Mar 6 17:37:45 1997 From: klm@CNRI.Reston.Va.US (Ken Manheimer) Date: Thu, 6 Mar 1997 12:37:45 -0500 (EST) Subject: [PYTHON DOC-SIG] Templatising gendoc, and more. In-Reply-To: <199703042206.RAA20200@anthem.CNRI.Reston.Va.US> Message-ID: On Tue, 4 Mar 1997, Barry A. Warsaw wrote: > > >>>>> "MH" == Mark Hammond writes: > > MH> Ive _always_ done this in __init__, and maybe we would find > MH> that the "most common usage" argument is more pervasive now? > > Indeed! If i'm tracking what the actual issue is here (making the contents of a package's __init__ module also be the contents of the package module itself?), then (1) i'm for it - it was actually part of my original design, and the prototype implementation, and (2) i am hoping to play with ni sometime soon, experimenting with making the __init__ module and the package module one and the same (in sys.modules), so the contents are intrinsically the same. (I am also hoping to take my first foray into profiling python, to explore prospects for optimizing ni.) Soon. > [...] > I was probably not clear (or I'm misunderstanding). I only put > sort-of meta-package documentation in __init__.py's docstring, and I > think it makes sense to flatten that into the package module's > namespace, since you are documenting the package. This will be the case if the two objects are actually one. For free! (In fact, the reduction of a module object makes for underhead, rather than over:-) We'll have to see if that'll work, though. Ken _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From guido@CNRI.Reston.Va.US Fri Mar 7 00:23:57 1997 From: guido@CNRI.Reston.Va.US (Guido van Rossum) Date: Thu, 06 Mar 1997 16:23:57 -0800 Subject: [PYTHON DOC-SIG] Bugs in documentation In-Reply-To: Your message of "Wed, 05 Mar 1997 23:38:59." <01BC29BE.67987120@asvs01.inext.cz> References: <01BC29BE.67987120@asvs01.inext.cz> Message-ID: <199703070023.QAA00024@monty> > I'm making a slow progress in reading docs, but I've found some bugs already. > > General bug: > In Library Reference, Chapter 2.1.4 are swapped descriptions of / and % operators. Quite fatal for unexperienced ... I don't see this bug. It says x/y is the quotient, x%y is the remainder. This is exactly as it is. > HTML downloadable docs: > ../icons directory referred in files is not included in .tar.gz package. Sorry. --Guido van Rossum (home page: http://www.python.org/~guido/) _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From tismer@tismer.com Thu Mar 6 21:45:44 1997 From: tismer@tismer.com (Christian Tismer) Date: Thu, 06 Mar 1997 22:45:44 +0100 Subject: [PYTHON DOC-SIG] Bugs in documentation References: <01BC29BE.67987120@asvs01.inext.cz> Message-ID: <331F3B08.5011@tismer.com> Tomas Valusek wrote: > > Hi, > > I'm making a slow progress in reading docs, but I've found some bugs already. > > General bug: > In Library Reference, Chapter 2.1.4 are swapped descriptions of / and % operators. Quite fatal for unexperienced ... Maybe you got mislead by the notation here x / y quotient of x and y --- (1) x % y remainder of x / y because x / y on integers really truncates to an integer, and x % y is the remainder of that? - chris _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From suir@nms.otc.com.au Tue Mar 25 03:20:22 1997 From: suir@nms.otc.com.au (Raymond Sui) Date: Tue, 25 Mar 1997 14:20:22 +1100 Subject: [PYTHON DOC-SIG] Gendoc Message-ID: <199703250320.OAA25346@tintin.pad.otc.com.au.otc.com.au> Hello Out There, I have just started playing around with gendoc. I untarred the whole thing and tried running it against a python file. However, I seem to come across the following problem: *** Importing gendoc Collecting information Generating documents for HTMLg Traceback (innermost last): File "./gendoc", line 7, in ? gendoc.main() ... File "./gendoc/formatters/HTMLgenFormatter.py", line 88, in html_rc import __ ImportError: No module named __ Does anybody out there know what the "__" module refers to? I tried looking through some python books but found nothing specifically related to this. Regards, Raymond _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From MHammond@skippinet.com.au Tue Mar 25 05:24:09 1997 From: MHammond@skippinet.com.au (Mark Hammond) Date: Tue, 25 Mar 1997 15:24:09 +1000 Subject: [PYTHON DOC-SIG] Gendoc Message-ID: <199703250425.OAA17112@minotaur.labyrinth.net.au> > However, I seem to come across the following problem: > > *** Importing gendoc > Collecting information > Generating documents for HTMLg > Traceback (innermost last): > File "./gendoc", line 7, in ? > gendoc.main() > ... > File "./gendoc/formatters/HTMLgenFormatter.py", line 88, in html_rc > import __ > ImportError: No module named __ > > Does anybody out there know what the "__" module refers to? I tried looking > through some python books but found nothing specifically related to this. The __ is used by the "ni" module. You will probably find you have the "formatters" directory on your path - it shouldnt be - the "ni" module allows Python to find it in the sub-directory automatically... Mark. _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From suir@nms.otc.com.au Tue Mar 25 05:31:33 1997 From: suir@nms.otc.com.au (Raymond Sui) Date: Tue, 25 Mar 1997 16:31:33 +1100 Subject: [PYTHON DOC-SIG] Gendoc Message-ID: <199703250531.QAA26873@tintin.pad.otc.com.au.otc.com.au> Oops, what I forgot to mention was that I encountered an initial problem with the ni module in gendoc. When I tried to run gendoc the first time, I got the following: Traceback (innermost last): File "./gendoc", line 2, in ? import ni File ".../python/imported/lib/1.4/ni.py", line 435, in ? File ".../python/imported/lib/1.4/ni.py", line 399, in install File ".../python/imported/lib/1.4/ihooks.py", line 364, in install File ".../python/imported/lib/1.4/ni.py", line 390, in install File ".../python/imported/lib/1.4/ni.py", line 239, in init_package File ".../python/imported/lib/1.4/ni.py", line 261, in call_init_module File ".../python/imported/lib/1.4/ni.py", line 204, in load_module File ".../python/imported/lib/1.4/ihooks.py", line 262, in load_module File ".../python/imported/lib/1.4/ihooks.py", line 173, in load_source File "./__init__.py", line 1, in ? path = __.__path__[0] TypeError: unsubscriptable object Any clues as to what's the problem here? Raymond > > > However, I seem to come across the following problem: > > > > *** Importing gendoc > > Collecting information > > Generating documents for HTMLg > > Traceback (innermost last): > > File "./gendoc", line 7, in ? > > gendoc.main() > > ... > > File "./gendoc/formatters/HTMLgenFormatter.py", line 88, in html_rc > > import __ > > ImportError: No module named __ > > > > Does anybody out there know what the "__" module refers to? I tried > looking > > through some python books but found nothing specifically related to this. > > The __ is used by the "ni" module. > > You will probably find you have the "formatters" directory on your path - > it shouldnt be - the "ni" module allows Python to find it in the > sub-directory automatically... > > Mark. > _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From dlarsson@sw.seisy.abb.se Tue Mar 25 08:14:42 1997 From: dlarsson@sw.seisy.abb.se (Daniel Larsson) Date: Tue, 25 Mar 1997 09:14:42 +0100 Subject: [PYTHON DOC-SIG] Gendoc References: <199703250320.OAA25346@tintin.pad.otc.com.au.otc.com.au> Message-ID: <33378972.2C75@sw.seisy.abb.se> Raymond Sui wrote: > > Hello Out There, > > I have just started playing around with gendoc. I untarred the whole thing > and tried running it against a python file. > > However, I seem to come across the following problem: > > *** Importing gendoc > Collecting information > Generating documents for HTMLg > Traceback (innermost last): > File "./gendoc", line 7, in ? > gendoc.main() > ... > File "./gendoc/formatters/HTMLgenFormatter.py", line 88, in html_rc > import __ > ImportError: No module named __ > > Does anybody out there know what the "__" module refers to? I tried looking > through some python books but found nothing specifically related to this. > > Regards, > Raymond > __ refers to the "package module". There is a description about packages in the docstring in ni.py. How is your sys.path defined? -- Daniel Larsson, ABB Industrial Systems AB _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From dlarsson@sw.seisy.abb.se Tue Mar 25 08:25:33 1997 From: dlarsson@sw.seisy.abb.se (Daniel Larsson) Date: Tue, 25 Mar 1997 09:25:33 +0100 Subject: [PYTHON DOC-SIG] Gendoc References: <199703250531.QAA26873@tintin.pad.otc.com.au.otc.com.au> Message-ID: <33378BFD.28F8@sw.seisy.abb.se> Raymond Sui wrote: > > Oops, what I forgot to mention was that I encountered an initial problem > with the ni module in gendoc. > When I tried to run gendoc the first time, I got the following: > > Traceback (innermost last): > File "./gendoc", line 2, in ? > import ni > File ".../python/imported/lib/1.4/ni.py", line 435, in ? > File ".../python/imported/lib/1.4/ni.py", line 399, in install > File ".../python/imported/lib/1.4/ihooks.py", line 364, in install > File ".../python/imported/lib/1.4/ni.py", line 390, in install > File ".../python/imported/lib/1.4/ni.py", line 239, in init_package > File ".../python/imported/lib/1.4/ni.py", line 261, in call_init_module > File ".../python/imported/lib/1.4/ni.py", line 204, in load_module > File ".../python/imported/lib/1.4/ihooks.py", line 262, in load_module > File ".../python/imported/lib/1.4/ihooks.py", line 173, in load_source > File "./__init__.py", line 1, in ? > path = __.__path__[0] > TypeError: unsubscriptable object > > Any clues as to what's the problem here? > > Raymond > The problem you have is probably that you are running against the untared distribution. Either you run 'make install' (check the definitions of PYTHON_BIN and PYTHON_LIB in the Makefile first), or you set up the *parent* directory of gendoc in $PYTHONPATH, and copy the 'gendoc' file to some directory in your $PATH. -- Daniel Larsson, ABB Industrial Systems AB _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From viennet@ura1507.univ-paris13.fr Fri Mar 28 21:15:22 1997 From: viennet@ura1507.univ-paris13.fr (viennet@ura1507.univ-paris13.fr) Date: Fri, 28 Mar 1997 22:15:22 +0100 Subject: [PYTHON DOC-SIG] Gendoc problem Message-ID: <199703282115.WAA24385@sapporo.ibp.fr> Hi, Sorry, but I can't get gendoc to work. I always get the error: AttributeError: render_deflist (I use gendoc 0.6, and installed using make install) Any help welcome. Here is the full traceback: % gendoc gendoc_test.py Traceback (innermost last): File "/usr/local/bin/gendoc", line 5, in ? gendoc.gendoc.main() File "/usr/local/lib/python1.4/gendoc/gendoc.py", line 229, in main render_manpages(formats, manpages, head) File "/usr/local/lib/python1.4/gendoc/gendoc.py", line 316, in render_manpages files = render_pages(manpages, formatter) File "/usr/local/lib/python1.4/gendoc/gendoc.py", line 337, in render_pages filename = render_page(page, formatter, prev, next) File "/usr/local/lib/python1.4/gendoc/gendoc.py", line 365, in render_page mantext = manpage.render(formatter) File "/usr/local/lib/python1.4/gendoc/ManualPage.py", line 322, in render apply(self._render_[child[0]], (formatter,)+tuple(child[1:])) File "/usr/local/lib/python1.4/gendoc/ManualPage.py", line 393, in _render_subsection apply(self._render_[child[0]], (formatter,)+tuple(child[1:])) File "/usr/local/lib/python1.4/gendoc/ManualPage.py", line 393, in _render_subsection apply(self._render_[child[0]], (formatter,)+tuple(child[1:])) File "/usr/local/lib/python1.4/gendoc/ManualPage.py", line 450, in _render_deflist formatter.render_deflist(self, list) AttributeError: render_deflist -- Emmanuel Viennet: LIPN - Institut Galilee - Universite Paris-Nord 93430 Villetaneuse - France _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From amk@magnet.com Mon Mar 31 22:34:25 1997 From: amk@magnet.com (Andrew Kuchling) Date: Mon, 31 Mar 1997 17:34:25 -0500 (EST) Subject: [PYTHON DOC-SIG] Documentation enhancements Message-ID: <199703312234.RAA08427@lemur.magnet.com> I've found a publisher who's somewhat interested in producing a printed version of the Python docs, though nothing is certain yet. In the knowledge that there may be a printed version of the 1.5 docs, what changes should be made? Gabriel Berriz made some excellent suggestions, where the priority is improving the index and adding cross-references from module to module. (For example, the rand module would also reference random.py and whrandom.py. Michael K. Johnson at Red Hat independently suggested the same improvement.) Regarding a printed version, what should be in it? Probably the big 4 should all be included: library, reference, extension manual, and tutorial. (Or can the tutorial be left out? I'd vote no, but...) Are there other documents that should be included? Possibilities: * qua.tex * The man page for the Python interpreter * Documentation for the matrix extensions? PIL? Something else? * Is there Windows or Mac documentation that could/should be included? Andrew Kuchling amk@magnet.com http://people.magnet.com/%7Eamk/ Save the Gutenberg Project! http://www.promo.net/pg/nl/pgny_nov96.html _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From da@maigret.cog.brown.edu Mon Mar 31 23:06:07 1997 From: da@maigret.cog.brown.edu (David Ascher) Date: Mon, 31 Mar 1997 18:06:07 -0500 (EST) Subject: [PYTHON DOC-SIG] Documentation enhancements In-Reply-To: <199703312234.RAA08427@lemur.magnet.com> Message-ID: > I've found a publisher who's somewhat interested in producing a > printed version of the Python docs, though nothing is certain yet. In > the knowledge that there may be a printed version of the 1.5 docs, > what changes should be made? I for one would want to make sure that we don't rush into something like this without making sure that the product is high-quality. I agree with ,I think it was you, Andrew, that the docs need a typesetting makeover at the very least. I also feel that the tutorial badly needs an overhaul -- right now most of the good stuff is in "and then we added ..." sections, which gives the wrong impression. I realize that the author of the tutorial (GvR) is too busy, but I do think it's an important and needed change... BTW: the reason I think it's important to do a good job is that I think this sort of product has a much bigger PR effect than one might think -- and first impressions count a lot. > Gabriel Berriz made some excellent suggestions, where the priority is > improving the index and adding cross-references from module to module. > (For example, the rand module would also reference random.py and > whrandom.py. Michael K. Johnson at Red Hat independently suggested > the same improvement.) The os/posix/etc. modules fall into that category as well. > Regarding a printed version, what should be in it? Probably the big 4 > * Documentation for the matrix extensions? I will update the Numeric tutorial a lot in the future -- it seems it'd be a shame to rush it out the door when it's not ready for prime time. --david _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________