On Thu, 2007-01-11 at 07:08 -0700, Steven H. Rogers wrote:
> I'd prefer reStructuredText. I don't find the markup particularly noisy and
> it quickly fades into the background.
I found some notes on the docutils page (about using reStructuredText in
docstring):
http://docutils.sourceforge.net/d
I'd prefer reStructuredText. I don't find the markup particularly noisy and
it quickly fades into the background.
Regards,
Steve
--
Steven H. Rogers, Ph.D., [EMAIL PROTECTED]
Weblog: http://shrogers.com/weblog
"He who refuses to do arithmetic is doomed to talk nonsense."
-- John McCarthy
_
Hi,
Overall I like your train of thought. If we're going use a modified
take on the structured text:
> Use *italics*, **bold**, and `courier` if needed in any explanations
> (but not for variable names and doctest code or multi-line code)
I've always been a fan of using /'s for italics, and si
On Wed, 2007-01-10 at 17:53 -0600, Robert Kern wrote:
> How are you viewing the docstrings that wouldn't associate the docstring with
> the function?
print .__doc__
Like so:
Python 2.4 (#1, Mar 22 2005, 21:42:42)
[GCC 3.3.5 20050117 (prerelease) (SUSE Linux)] on linux2
Type "help", "co
Christian Marquardt wrote:
> Very nice!
>
>> """
>> one-line summary not using variable names or the function name
>
> I would personally prefer that the first name contains the function (but
> nor arguments) - that way, when you are scrolling back in your terminal,
> or have a version printed o
Christian Marquardt wrote:
>Very nice!
>
>
>
>>"""
>>one-line summary not using variable names or the function name
>>
>>
>
>I would personally prefer that the first name contains the function (but
>nor arguments) - that way, when you are scrolling back in your terminal,
>or have a version
Very nice!
> """
> one-line summary not using variable names or the function name
I would personally prefer that the first name contains the function (but
nor arguments) - that way, when you are scrolling back in your terminal,
or have a version printed out, you know what function/method the
doc
There was a lively discussion on the SciPy List before Christmas
regarding establishing a standard for documentation strings for NumPy /
SciPy.
I am very interested in establishing such a standard. A hearty thanks
goes to William Stein for encouraging the discussion. I hope it is
very clear