and - one for "structural" elements, and one for inline elements (I forget which is which), and TeX and LaTeX are well-known for their use of grouping (e.g., the ``\begin{xxx}`` and ``\end{xxx}`` in LaTeX). I don't consider it worth making the

/ distinction in the context of a tree - it is perfectly evident what is beingp grouped from the elements themselves. Once one has a element, it is natural to annotate it with *what* it is a group of/for. I chose the arbitrary term "style" - partly because it is not used in HTML/XML for any purpose I am aware of. And once one has the "style" attribute, it becomes possible to use it elsewhere - most notably in

elements, saving the need for a myriad of different sections for different purposes. In these instances, it is perhaps acting more like the "class" attribute in HTML - indicating, to some extent, meaning, but aimed mostly at presentation (via CSS). The other obvious place to use it is in the automatically generated text for things like names, where (at least pre-"combing"/transformation) one is "pretending" to have assigned a role (just as a person might in a docstring) (but see [#style]_). Summary ------- Current DPS defines many element types for use in Python code representation. However, there are major advantages in only using the "simple" DPS nodes for all purposes. This becomes simple and practical given a single extra, general purpose, element: . Furthermore, adding a standard attribute called "style" (or perhaps "role" - see [#style]_) seems to fulfil any other outstanding requirements. References ---------- .. [#diagram] in email by David Goodger to Doc-SIG, dated 21 September 2001 04:31, "Re: [Doc-SIG] DPS components". .. [#style] Hmm - maybe "style" should be "role", to match with the way that a :role:`of something` gets handled... .. [#pydps] Normally to be found at http://www.tibsnjoan.co.uk/reST/pydps.tgz, although note that this is not currently up-to-date. .. [#nodes] dps/dps/nodes.py in the DPS distribution (``dps.nodes`` if one is importing it). .. ############################################################ .. end:: reST included text Tibs -- Tony J Ibbs (Tibs) http://www.tibsnjoan.co.uk/ "No one trike will do everything... buy the whole set!" - Rob Hague My views! Mine! Mine! (Unless Laser-Scan ask nicely to borrow them.) From tony@lsl.co.uk Mon Nov 19 14:45:33 2001 From: tony@lsl.co.uk (Tony J Ibbs (Tibs)) Date: Mon, 19 Nov 2001 14:45:33 -0000 Subject: [Doc-SIG] Last Friday, "groups", washing machines - addendum In-Reply-To: <01c701c170eb$9c2a06f0$545aa8c0@lslp862.int.lsl.co.uk> Message-ID: <01c801c17108$d788fa40$545aa8c0@lslp862.int.lsl.co.uk> One important thing I forgot to say: It is not possible to insert a into a DPS tree by use of reST alone (well, subject to not doing sophisticated/complicated substitions a la Jaffray - but that's such an escape clause I shall ignore it). That is, there is no reST "spelling" of . elements are *only* intended to be inserted by things which manipulate the DPS tree directly - i.e., linkers and trasformers. Furthermore, a "plain" DPS writer is perfectly at liberty (and may perhaps be expected) to treat a element as if it had no representation - for instance, in my own "plain" HTML Writer class:: def write_group(self,element,stream): """By default, we don't do anything with tags. """ for node in element: self.write_html(node,stream) Alternatively (in HTML output) a reasonable response would be to translate it to

or as appropriate - but that is *not requried*. Tibs -- Tony J Ibbs (Tibs) http://www.tibsnjoan.co.uk/ Marked up with reStructuredText: http://structuredtext.sf.net/ My views! Mine! Mine! (Unless Laser-Scan ask nicely to borrow them.) From goodger@users.sourceforge.net Tue Nov 20 04:01:39 2001 From: goodger@users.sourceforge.net (David Goodger) Date: Mon, 19 Nov 2001 23:01:39 -0500 Subject: [Doc-SIG] scope of the parser In-Reply-To: Message-ID: Alan: > > > 95% of the time the desired behavior for directives will be to > > > process the block argument as RST, and not do any other RST > > > processing. In those cases, you can decouple. If you want > > > something else, you have to muck with the inside of the parser. David: > > I don't follow. Can you give an example of a directive in the > > other 5%? Alan: > A directive indicating an indexed and captioned code fragment:: > > .. example:: index=2.2 caption=`Recognizing inline markup` > inline.openers = '\'"([{<' > inline.closers = '\'")]}>' > inline.start_string_prefix = (r'(?:(?<=^)|(?<=[ \n%s]))' > % re.escape(inline.openers)) > inline.end_string_suffix = (r'(?:(?=$)|(?=[- \n.,:;!?%s]))' > % re.escape(inline.closers)) I don't see how this is an example of a non-RST (or post-RST) directive. It seems like a simple variant of a literal block. Perhaps it depends on what the "index" and "caption" do? However, the second example is easier to understand: > A directive indicating raw output for a given format:: > > .. raw:: format=latex > \documentclass[twocolumn]{article} I assume this is to be passed through to the LaTeX writer untouched. Easy to accomplish. The "raw" directive should produce something like this:: \documentclass[twocolumn]{article} Even better would be if the element name was "raw-latex". Either way, there are two possibilities here: 1. A directive becomes widespread enough to warrant built-in support. The DTD, dps.nodes, and all writers learn about it (some may learn to ignore it). 2. It's of limited application-specific use. The application's code needs a dps.nodes.Node subclass (probably subclass of TextElement) to handle it, the application may need a DTD extension [#]_, and the application's writer variants need support. .. [#] Currently, the DTD is used only as a formalized notation of the DPS doc tree implemented in dps.nodes. In future, there might be direct doc tree validation support added to the code, which may use the DTD or some other notation (such as TREX or RELAX). > > What do you mean by "decouple"? > > Do directive processing outside the parser, and in fact outside the > entire DPS/RST codebase. Do you mean "processing using code outside the DPS/RST project codebase, but still run interleaved with it" or "processing after the DPS/RST codebase has finished its work"? The former can be done now. The latter, I'm not sure about. > If a user comes along and decides they want a new directive, they > ought to be able to do this while treating RST as a black box. I don't agree. You need a degree of understanding of the inner workings of a system in order to extend it. Adding a directive might require a less than complete understanding of the internals, but not none. > User feeds in ``.. foo:: bar``, gets back `` args="bar"/>``, and can then process the XML into whatever they > want, or treat it as a literal, or output a warning, or whatever. The problem with this is that error checking goes out the window. A directive with a misspelled type name would trigger no warnings in the parser, and possibly not even in the writer. If application-specific directives appear that cannot or should not be added to the core parser, the current code can't handle it. In order to add a directive, you have to put the directive implementation module into the restructuredtext/directives directory, and edit project source files: restructuredtext/directives/__init__.py for a canonical directive name to (module name, function name) mapping, and restructuredtext/languages/en.py for a language-specific to canonical name mapping. This shortcoming could be remedied to allow runtime additions to the "directive registry", with implementation modules outside of the parser's package tree. -- David Goodger goodger@users.sourceforge.net Open-source projects: - Python Docstring Processing System: http://docstring.sourceforge.net - reStructuredText: http://structuredtext.sourceforge.net - The Go Tools Project: http://gotools.sourceforge.net From goodger@users.sourceforge.net Tue Nov 20 04:24:05 2001 From: goodger@users.sourceforge.net (David Goodger) Date: Mon, 19 Nov 2001 23:24:05 -0500 Subject: [Doc-SIG] Re: Adding , losing and their ilk In-Reply-To: <01c801c17108$d788fa40$545aa8c0@lslp862.int.lsl.co.uk> Message-ID: (I've dropped the washing machine reference from the title because it's TOO SILLY!) Tony J Ibbs (Tibs) wrote: > Whilst David's diagram is not *quite* how I see the process, it's > close enough for this purpose. Thus pydps [#pydps]_ might be shown > as:: > > +--------+ +--------------+ +------------+ +---------+ > | READER | --> | transform.py | --> | transforms | --> | html.py | > +--------+ +--------------+ +------------+ +---------+ > | | > +----------+ +---------------+ > | visit.py | | buildhtml.py | > +----------+ +---------------+ > > The "READER" is implicit in the main utility (currently > ``pydps.py``), and locates the relevant Python files. It then > uses ``visit.py`` to generate a tree representing the Python code I'd consider ``visit.py`` to be part of the Reader. > So, in summary: > > 1. ``transform.py`` generates a *normal* DPS tree. It doesn't > use any "odd" nodes (except - but we'll discuss > that later on). This means that it should be possible to > plug in any other writer, and produce a different format as > output - a very significant advantage. Substitute "The Reader" for "transform.py" and: Yes. In the revised model, the Reader subsumes the transforms. > 2. ``html.py`` expects to be given a *normal* DPS tree. This > means that it should be usable by any other utility that > also provides a normal DPS tree - again an advantage. Ditto "The Writer" for "html.py": Yes. > The problem > ----------- > But there is a clash in requirements here. Whilst it is very nice > to be able to represent the Python information as "normal" DPS > (guaranteeing that anyone can do useful things with it), there is > some need to transfer information that goes beyond that. There > are two main reasons for wanting to do this: > > * Data mining > * Presentation > > For the first, although DPS/reST/pydps is primarily about > producing human-viewable documentation, it might also be nice to > be able to extract parts of it automatically, for various > purposes - for instance, retrieve just the information about > which classes inherit from other. This information will, in part, > be obvious from the text chosen within the document (a title like > "Class Fred" might be taken to be useful, for instance!), but it > would be nice to give a bit more help. Wouldn't that be better left to a tool accessing the information directly? (Correct me if I'm wrong...) Your visit.py extracts structural information from the AST via compiler.py, and transforms it into the trunk and major branches of the doc tree, onto which the parsed docstrings get attached like minor branches and leaves. The doc tree is one step removed from the AST; I would think that a data mining application would want to start as close to the source AST data as possible. I wouldn't want to try to extract such structural information from textual clues. There are certain limits on such operations (as we all well know). > For the second, it's relatively difficult to produce better > layout for DPS Python documentation without more information to > work on. If one uses the (rather garish) default presentation > produced by pydps (and no, I'm not saying that's a *nice* > presentation, but it is the one I've got as an example), it is > clearly useful to be able to: > > 1. group together the package/class/method/etc title and its > full name/path/whatever > > 2. group together a method or function's signature and its > docstring I would say that's a job for the Reader and its tranforms, not for the Writer. Let me elaborate a bit more on the latest diagram:: 1,3,5 6,8 +--------+ +--------+ | READER | =======================> | WRITER | +--------+ (purely presentational) +--------+ // \ / \ // \ / \ 2 // 4 \ 7 / 9 \ +--------+ +------------+ +------------+ +---------------+ | PARSER |...| reader | | writer |...| deployment | +--------+ | transforms | | transforms | | | | | | | | - one file | | - docinfo | | - styling | | - many files | | - titles | | - writer- | | - object data | | - linking | | specific | | structure | | - lookups | | - etc. | +---------------+ | - reader- | +------------+ | specific | | - parser- | | specific | | - layout | | - etc. | +------------+ I've added double-width lines between reader & parser and between reader & writer, meaning that data sent along these paths should be standard (pure & unextended) DPS doc trees. Single-width lines signify that internal tree extensions are OK (but must be supported internally at both ends), and may in fact be totally unrelated to the DPS doc tree structure. I've added "reader-specific" and "layout" transforms to the list of transforms. BTW, these transforms are not necessarily all in one directory; it's a nebulous grouping (it's hard to draw ASCII clouds). I've also added numbers to show the path a document would take through the code. > David's original approach to this was to introduce a host of > Python specific tags into ``nodes.py`` [#nodes]_ - for instance:: > > package_section > module_section > ... > instance_attribute_section > ... > parameter_item > parameter_tuple > ... > package > module > class_attribute > > There are several problems with approach. Perhaps the most > serious is that *all* generic DPS writers need to understand > this host of elements that are only relevant to Python. Clearly, > someone writing a writer for other purposes may be reluctant to > go to this (to them) redundant effort. I think the Python-specific extensions should be removed from dps.nodes and relocated to the PySource Reader for Reader-internal use only. The DTDs have been split since the beginning: gpdi.dtd for generic elements, and pdpi.dtd for Python-specific stuff. Writer modules should support only the standard doc tree elements, and should be considered "presentation only". I'm sure there are lots of changes to the doc tree structure that can be made for the benefit of Writers. The only reason there aren't any presentation-oriented attributes on elements is that nobody's added them yet. > From my point of view, an immediate problem is that the set of > elements is not *quite* what I want - which means working towards > a set of patches for ``nodes.py`` and the relevant DTD, and > getting David to agree to them (well, that last is a useful > process to have in place, but still). Since I'm not likely to get > it right immediately, this is a repetitive process. If we extract the Python-specific stuff out of dps.nodes, you'll have a free hand to do whatever you like within the PyDPS/PySource Reader. > Lastly, one might imagine someone from another programming > language domain adopting DPS/reST. One can expect them to be > frustrated if the set of constructs provided for Python doesn't > quite match the set of constructs required to describe their > language in a natural manner. So they write the LanguageXSource Reader with their own language-specific extensions. They'd have to anyway since compiler.py won't help them. > Groups and "style" > ------------------ > The first thing that I realised was that, for convenience of > output at least, I wanted to be able to group elements together - > or, in terms of the DPS tree, insert an arbitrary "subroot" > within the tree to 'abstract' a branch of the tree. > > This is particularly useful for linking together the parts of the > text that deal with (for instance) attribution, or unusual > globals, without having to embed yet another section. That was the purpose of the Python-specific elements in ppdi.dtd. But they were just my first guess at what would be needed; feel free to modify as necessary. > Once one has a element, it is natural to annotate it with > *what* it is a group of/for. I chose the arbitrary term "style" - > partly because it is not used in HTML/XML for any purpose I am > aware of. > > And once one has the "style" attribute, it becomes possible to > use it elsewhere - most notably in

elements, saving the > need for a myriad of different sections for different purposes. I can see using a "style" attribute to communicate formatting information between the Reader and the Writer (which would be free to ignore the advice if not understood). I'd much rather have a bunch of different section-level classes than one class with a "style" attribute. With section-level classes, we can use polymorphism to advantage. Plus, the classes are significantly different. Here's one:: The "package" element is just a replacement for a generic section's "title". It is easier to hang boilerplate text or formatting onto a specific element though. But here's another:: The "class" element contains the class name; it's the section title. But then there's an inheritance list and parameter list; much more interesting. If you had a generic "group" element, *and* you wanted an "inheritance_list" sometimes, you'd have to allow it anywhere, even when it's not applicable. You'd either end up with a freeform doc tree structure or one that's impossible to validate. > Summary > ------- > Current DPS defines many element types for use in Python code > representation. Gut 'em. > However, there are major advantages in only using the "simple" > DPS nodes for all purposes. True. > This becomes simple and practical given a single extra, general > purpose, element: . Nah. (For the same reason we don't use DOM: too general.) > Furthermore, adding a standard attribute called "style" (or > perhaps "role" - see [#style]_) seems to fulfil any other > outstanding requirements. Could be... -- David Goodger goodger@users.sourceforge.net Open-source projects: - Python Docstring Processing System: http://docstring.sourceforge.net - reStructuredText: http://structuredtext.sourceforge.net - The Go Tools Project: http://gotools.sourceforge.net From tony@lsl.co.uk Tue Nov 20 11:26:59 2001 From: tony@lsl.co.uk (Tony J Ibbs (Tibs)) Date: Tue, 20 Nov 2001 11:26:59 -0000 Subject: [Doc-SIG] RE: Adding , losing and their ilk In-Reply-To: Message-ID: <01e601c171b6$44988f80$545aa8c0@lslp862.int.lsl.co.uk> David Goodger wrote: > (I've dropped the washing machine reference from the title because > it's TOO SILLY!) That's OK - I hadn't thought about people's "subject" fields when they're *replying* to the message! There's a lot for me to digest in your reply - I shall have to mull it over properly. Clearly I've still to understand the deep meaning of the DPS way - but then working this sort of thing out leads one ever closer. By the way - the diagram is getting better every time! Specific replies/comments another time. Tibs -- Tony J Ibbs (Tibs) http://www.tibsnjoan.co.uk/ "No one trike will do everything... buy the whole set!" - Rob Hague My views! Mine! Mine! (Unless Laser-Scan ask nicely to borrow them.) From goodger@users.sourceforge.net Tue Nov 20 13:19:13 2001 From: goodger@users.sourceforge.net (David Goodger) Date: Tue, 20 Nov 2001 08:19:13 -0500 Subject: [Doc-SIG] Re: Adding , losing and their ilk In-Reply-To: <01e601c171b6$44988f80$545aa8c0@lslp862.int.lsl.co.uk> Message-ID: Tony J Ibbs (Tibs) wrote: > By the way - the diagram is getting better every time! It's got a nice symmetry to it now, doesn't it? -- David Goodger goodger@users.sourceforge.net Open-source projects: - Python Docstring Processing System: http://docstring.sourceforge.net - reStructuredText: http://structuredtext.sourceforge.net - The Go Tools Project: http://gotools.sourceforge.net From amos@zope.com Thu Nov 22 00:52:19 2001 From: amos@zope.com (Amos Latteier) Date: Wed, 21 Nov 2001 16:52:19 -0800 Subject: [Doc-SIG] Getting started with restructured text Message-ID: <3BFC4C43.7000603@zope.com> Hi, I don't know much about restx, but what I've seen so far impresses me. The spec seems well thought out. I currently use structured text quite a bit. In fact I've written a book with it. I am painfully aware of shortcomings in structured text. I'd like to evaluate restx as an alternative for writing articles and books. I downloaded the latest cvs snapshot and tried to figure out how to get going. I ran into a couple problems: * distutils doesn't add __init__.py files to the dps and parsers directories that it creates. This means that they aren't considered packages. I don't know if this is a distutils bug or a problem with how restx uses distutils. * restx seems to require that the entire dps package be installed. * There is no obvious way to create HTML output. Should I write an HTML formatter along the lines shown in dps.formatters.model? Or is XSLT preferred? Thanks for any pointers. -Amos -- Amos Latteier amos@zope.com Zope Corporation http://www.zope.com/ From goodger@users.sourceforge.net Thu Nov 22 03:46:22 2001 From: goodger@users.sourceforge.net (David Goodger) Date: Wed, 21 Nov 2001 22:46:22 -0500 Subject: [Doc-SIG] Getting started with restructured text In-Reply-To: <3BFC4C43.7000603@zope.com> Message-ID: Hi Amos, > I don't know much about restx, but what I've seen so far impresses me. > The spec seems well thought out. Thanks! We aim to please. > * distutils doesn't add __init__.py files to the dps and parsers > directories that it creates. This means that they aren't considered > packages. I don't know if this is a distutils bug or a problem with how > restx uses distutils. That's odd. There *are* __init__.py files in those directories in CVS. I just checked the latest CVS snapshot, and the files are there too. The snapshots are generated daily but not archived (CVS is the archive); it's possible that there may have been a glitch in the snapshot you downloaded. Glitches been known to happen, but they've generally been all-or-nothing (the SourceForge CVS repository is unavailable when the script is run, etc.). Perhaps it is a distutils thing? I can't say; I've been running code from my local CVS tree. I'll make a point of periodically making sure setup.py/install.py work correctly. Those two files are just empty package indicators though. Others are not. > * restx seems to require that the entire dps package be installed. Yes. reStructuredText is a part of the DPS project. I felt it best to keep them separate as I wanted to allow for alternate syntaxes (StructuredText classic/NG, Setext, TeX, XML, or anything else anybody wanted to hack on). DPS is currently little more than support for the reStructuredText parser though. I plan to merge the two projects at some point into the "docutils" project, but I want to leave it until the ideas and APIs have matured. The parser is nearly complete, but the rest of the system isn't there yet. > * There is no obvious way to create HTML output. Should I write an HTML > formatter along the lines shown in dps.formatters.model? Or is XSLT > preferred? That's up to you! Tony Ibbs has produced a first stab at what I call a "Reader", a Python source analyzer, and an HTML "Writer", still available at http://www.tibsnjoan.co.uk/reST/pydps.tgz. It's no longer being maintained in favour of a fabled new implementation (which I'd love to see one of these days). Several contributors have produced XSL stylesheets; they're available in the reStructuredText "sandbox". Unfortunately, they're not up to date. I plan to create a standalone Reader (i.e., input consists of standalone reStructuredText source files without context), but haven't had time yet. This is definitely a work in progress. Contributions would be most appreciated! -- David Goodger goodger@users.sourceforge.net Open-source projects: - Python Docstring Processing System: http://docstring.sourceforge.net - reStructuredText: http://structuredtext.sourceforge.net - The Go Tools Project: http://gotools.sourceforge.net From Juergen Hermann" Message-ID: On Wed, 21 Nov 2001 22:46:22 -0500, David Goodger wrote: >Perhaps it is a distutils thing? I can't say; I've been running code fr= om my >local CVS tree. I'll make a point of periodically making sure >setup.py/install.py work correctly. > >Those two files are just empty package indicators though. Others are no= t. Given this info, it's a WinZIP thing, which NEVER unpacks empty files. J= ust add a docstring, as you should anyway ;), and the problem is solved. Ciao, J=FCrgen -- J=FCrgen Hermann, Developer (jhe@webde-ag.de) WEB.DE AG, http://webde-ag.de/ From tony@lsl.co.uk Thu Nov 22 10:26:42 2001 From: tony@lsl.co.uk (Tony J Ibbs (Tibs)) Date: Thu, 22 Nov 2001 10:26:42 -0000 Subject: [Doc-SIG] Getting started with restructured text In-Reply-To: Message-ID: <021301c17340$2dd9bc70$545aa8c0@lslp862.int.lsl.co.uk> David Goodger wrote: > Tony Ibbs has produced a first stab at what I call a > "Reader", a Python source analyzer, and an HTML "Writer", > still available at > http://www.tibsnjoan.co.uk/reST/pydps.tgz. It's no longer > being maintained in favour of a fabled new implementation > (which I'd love to see one of these days). Erm, well, I wouldn't say "no longer being maintained" - I still haven't changed the name. I *did* try to upload a new version this morning, but something has gone wrong with my ability to upload (password changed under my feet), so I'm awaiting a reply from "customer services" before I can do anything more. If Amos wants a copy urgently, I can always email it to him - it seems to cope adequately with "plain" reST text, although it's a bit behind the times on some subtleties that have been changing lately! Tibs -- Tony J Ibbs (Tibs) http://www.tibsnjoan.co.uk/ .. "equal" really means "in some sense the same, but maybe not .. the sense you were hoping for", or, more succinctly, "is .. confused with". (Gordon McMillan, Python list, Apr 1998) My views! Mine! Mine! (Unless Laser-Scan ask nicely to borrow them.) From goodger@users.sourceforge.net Thu Nov 22 23:37:14 2001 From: goodger@users.sourceforge.net (David Goodger) Date: Thu, 22 Nov 2001 18:37:14 -0500 Subject: [Doc-SIG] Getting started with restructured text In-Reply-To: Message-ID: David Goodger wrote: >> Perhaps it is a distutils thing? I can't say; I've been running code from my >> local CVS tree. I'll make a point of periodically making sure >> setup.py/install.py work correctly. >> >> Those two files are just empty package indicators though. Others are not. Juergen Hermann wrote: > Given this info, it's a WinZIP thing, which NEVER unpacks empty files. Just > add a docstring, as you should anyway ;), and the problem is solved. Actually, they have a few lines of comments each, so they're not *completely* empty. -- David Goodger goodger@users.sourceforge.net Open-source projects: - Python Docstring Processing System: http://docstring.sourceforge.net - reStructuredText: http://structuredtext.sourceforge.net - The Go Tools Project: http://gotools.sourceforge.net From amos@zope.com Mon Nov 26 18:20:19 2001 From: amos@zope.com (Amos Latteier) Date: Mon, 26 Nov 2001 10:20:19 -0800 Subject: [Doc-SIG] Getting started with restructured text References: Message-ID: <3C0287E3.8000604@zope.com> David Goodger wrote: >>* distutils doesn't add __init__.py files to the dps and parsers >>directories that it creates. This means that they aren't considered >>packages. I don't know if this is a distutils bug or a problem with how >>restx uses distutils. >> > > That's odd. There *are* __init__.py files in those directories in CVS. I > just checked the latest CVS snapshot, and the files are there too. I think the problem was that I was trying to use rstx without installing dps. >>* There is no obvious way to create HTML output. Should I write an HTML >>formatter along the lines shown in dps.formatters.model? Or is XSLT >>preferred? >> > > That's up to you! Tony Ibbs has produced a first stab at what I call a > "Reader", a Python source analyzer, and an HTML "Writer", still available at > http://www.tibsnjoan.co.uk/reST/pydps.tgz. It's no longer being maintained > in favour of a fabled new implementation (which I'd love to see one of these > days). Several contributors have produced XSL stylesheets; they're available > in the reStructuredText "sandbox". Unfortunately, they're not up to date. > > I plan to create a standalone Reader (i.e., input consists of standalone > reStructuredText source files without context), but haven't had time yet. > > This is definitely a work in progress. Contributions would be most > appreciated! I'm working on a HTML formatter which I'll contribute. Thanks! -Amos -- Amos Latteier amos@zope.com Zope Corporation http://www.zope.com/ From fdrake@acm.org Mon Nov 26 21:38:59 2001 From: fdrake@acm.org (Fred L. Drake) Date: Mon, 26 Nov 2001 16:38:59 -0500 (EST) Subject: [Doc-SIG] [development doc updates] Message-ID: <20011126213859.1A7AE28696@cj42289-a.reston1.va.home.com> The development version of the documentation has been updated: http://python.sourceforge.net/devel-docs/ Various small corrections and additions. From goodger@users.sourceforge.net Tue Nov 27 05:43:20 2001 From: goodger@users.sourceforge.net (David Goodger) Date: Tue, 27 Nov 2001 00:43:20 -0500 Subject: [Doc-SIG] yummy treats! Message-ID: It really was only meant as a joke... >From the reStructuredText home page: If you can test, administrate, or contribute code, ideas, bug reports, yummy treats, computer equipment, and/or large sums of money, please `contact the project administrator`_. .. _contact the project administrator: me_ Got a call from my wife today. Seems a package arrived at our door, addressed to me but "'re: structured text', what does that mean?". I get home, and my 4-year-old son helps me to sift through the styrofoam peanuts to dig out a seemingly endless assortment of delectables, from caramel corn to ginger chews (*way* too spicy for my taste, but I'm sure we'll find them a good home), from light-as-feathers lemon meringues to a "Pound Plus" (500g) bar of Belgian bittersweet chocolate. About a cubic foot of yummy treats. Thanks Alan! Whatever possessed you? Now if only someone would send me a nice new (or even slightly used) laptop. Boy would the rate of checkins ever go up then! JUST KIDDING!!! (well...) -- David Goodger goodger@users.sourceforge.net Open-source projects: - Python Docstring Processing System: http://docstring.sourceforge.net - reStructuredText: http://structuredtext.sourceforge.net - The Go Tools Project: http://gotools.sourceforge.net From tony@lsl.co.uk Tue Nov 27 16:08:15 2001 From: tony@lsl.co.uk (Tony J Ibbs (Tibs)) Date: Tue, 27 Nov 2001 16:08:15 -0000 Subject: [Doc-SIG] yummy treats! In-Reply-To: Message-ID: <000201c1775d$b8d64ac0$545aa8c0@lslp862.int.lsl.co.uk> > It really was only meant as a joke... > > Thanks Alan! Whatever possessed you? Damn - he got in first (but congrats to Alan on actually *doing* it! and in such an impressive manner). I'm still thinking of investigating the depths of Glaswegian confectionary [1]_ after Christmas, though (we'll be visiting relatives). > Now if only someone would send me a nice new (or even > slightly used) laptop. Hmm - I'm afraid I've only just bought my own (slightly used) laptop, and you shan't have it except over my cold, dead, etc. But if someone else wants to chip in... Tibs .. [1] Glasgow, where they test sweets, 'cos if it doesn't sell in Glasgow it won't sell anywhere. ...where they sell half-pound bars of Caramac (a substance almost but not entirely unlike chocolate, except sweeter). ...where I first had tablet (basically, take condensed milk and render it down into a solid...) Glasgow, a good place to be a dentist. -- Tony J Ibbs (Tibs) http://www.tibsnjoan.co.uk/ "I'm a little monster, short and stout Here's my horns and here's my snout When you come a calling, hear me shout I will ROAR and chase you out" My views! Mine! Mine! (Unless Laser-Scan ask nicely to borrow them.) From fdrake@acm.org Wed Nov 28 07:57:33 2001 From: fdrake@acm.org (Fred L. Drake) Date: Wed, 28 Nov 2001 02:57:33 -0500 (EST) Subject: [Doc-SIG] [development doc updates] Message-ID: <20011128075733.9558928696@beowolf.digicool.com> The development version of the documentation has been updated: http://python.sourceforge.net/devel-docs/ Minor updates; mostly changed organization of the "Internet Data Handling" chapter. From fdrake@acm.org Thu Nov 29 08:48:05 2001 From: fdrake@acm.org (Fred L. Drake) Date: Thu, 29 Nov 2001 03:48:05 -0500 (EST) Subject: [Doc-SIG] [development doc updates] Message-ID: <20011129084805.0885328696@beowolf.digicool.com> The development version of the documentation has been updated: http://python.sourceforge.net/devel-docs/ Added section of example regular expressions to the "re" module docs. Various small clarifications. From fdrake@acm.org Fri Nov 30 06:10:49 2001 From: fdrake@acm.org (Fred L. Drake) Date: Fri, 30 Nov 2001 01:10:49 -0500 (EST) Subject: [Doc-SIG] [development doc updates] Message-ID: <20011130061049.B6ACB28696@beowolf.digicool.com> The development version of the documentation has been updated: http://python.sourceforge.net/devel-docs/ Updated the httplib docs to cover the API provided in recent versions of Python. Please review and comment on this and all other new material! (In case you have forgetten, other large chunks of new material include the sections covering modules in the email package, the compiler package, and the Tkinter/Tix chapter.)