[Doc-SIG] Evolution of library documentation
Edward D. Loper
Tue, 13 Mar 2001 18:07:45 EST
> Well, a reference manual is sometimes at a higher level than what I put
> in docstrings. But maybe I should be prefixing more methods with '_'.
It may make sense to have some place other than docstrings for reference
manual docs, if someone chooses to use it. But I think that docstrings
could give a very good "default" reference manual entry. Of course,
I tend to be very thorough in my commenting & documenting. :)
> > I think that we should leave the organization of "grander scope"
> > documentation to a different project.. (Of course, it's still
> > an important project.)
> Yes, yes, yes (indeed, I thought that's what was already being done,
> quietly in the background, by our Mr Drake)
Good to hear.
> (the whole issue of how one
> quotes things in ST is a difficult one, single quote itself is enough of
> a problem. The "true ST" approach, I think, is to say "borderline case -
> punt it - we're not that complex", which *may* well be the correct
I don't see why it has to be a difficult issue, but hopefully someone
will explain it to me. :) But I disagree that the "true ST" approach
is to say "borderline case - punt it." I think that's the approach
of most *current implementations* of ST, not of ST itself. If ST is
to become accepted and useful, we *do* need to define borderline cases,
or at least make them explicitly undefined. It really sucks to try
to use a language/markup that keeps changing under your feet, and is
inconsistant between tools. :)
> BUT whilst I don't mind reserving it, I'll probably oppose using it!
> (but allowing you to reserve it postpone the argument, which is a Very
> Good Thing, and it gives us a *marker* for having postponed the
Hm.. so unless anyone objects, we'll reserve it for now, with the
understanding that it may become unreserved later, or it may become
> STpy is almost as complex as I want it to get already - I want to add in
> [references] and then feature freeze. Which would have become clear in
> the alpha (he whines)
I'm still unclear about this [references] thing; explain it?
But I do agree that ST is complex enough. (btw, why do we need
3 different unordered list bullets? That seemed like enormous
overkill to me, and getting rid of 'o' as a bullet would solve
some problems with foreign languages.. Any chance that we could
just standardize on *either* '*' or '-'? I guess the STNG people
won't like that though...)
> Well, actually it's "Arguments". And the special meaning isn't
> *enforced* in the current implementation or documentation, but it may be
> in the future (so much to do, so little whatever).
I think of arguments as values you give a function, and parameters
as the slots to receive them. But I mainly chose "parameters" to
be consistant with javadoc etc. Doesn't really matter to me what
we call it.
> > author -- Edward Loper
> > version -- 2.71828
> Author: Edward Loper
> Version: 2.71828
> and it doesn't work yet (because '<keyword>:' doesn't yet start a
> paragraph) - it may or may not work in the alpha release.
As I argued in a previous email, I really think it should be description
list items, but I'll wait for you to argue your case.. :)
> > Then you just have to worry about syntax for inline markup. I don't
> > have any great ideas there, other than having a whole class of
> > "advanced inline markup" tags like @somethingorother(...)
> Given the '@' reserved, we can leave that...
Agreed. Any further inline markup will be left for another day.