Hi,<br>
<br><div><span class="gmail_quote">On 9/21/06, <b class="gmail_sendername">Robert Kern</b> &lt;<a href="mailto:robert.kern@gmail.com">robert.kern@gmail.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Steve Lianoglou wrote:<br>&gt; So .. I guess I'm wondering why we want to break from the standard?<br><br>We don't as far as Python code goes. The code that Chuck added Doxygen-style<br>comments to was C code. I presume he was simply answering Sebastian's question
<br>rather than suggesting we use Doxygen for Python code, too.</blockquote><div><br>
Exactly. I also don't think the Python hack description applies to
doxygen any longer. As to the oddness of \param or @param, here is an
example from Epydoc using Epytext<br>
<pre><code class="string">    <code class="field">@type  m:</code> number<br>    <code class="field">@param m:</code> The slope of the line.<br>    <code class="field">@type  b:</code> number<br>    <code class="field">@param b:
</code> The y intercept of the line.  The X{y intercept} of a</code></pre>
Looks like they borrowed something there ;) The main advantage of
epydoc vs doxygen seems to be that you can use the markup inside the
normal python docstring without having to make a separate comment
block. Or would that be a disadvantage? Then again, I've been thinking
of moving the python function docstrings into the add_newdocs.py file
so everything is together in one spot and that would separate the
Python docstrings from the functions anyway.<br>
<br>
I'll fool around with doxygen a bit and see what it does. The C code is the code that most needs documentation in any case.<br>
<br>
Chuck<br>
</div></div><br>