hellooreo.blogg.se - Doxygen param type python

#Doxygen param type python how to#
#Doxygen param type python upgrade#
#Doxygen param type python windows#

The tool chain should be as standard as possible with a low maintenance effort required from developers.

#Doxygen param type python windows#

Installing the system for publishing the documentation shouldn't be difficult and should work for Unix, Windows and Mac.

The new format should be easily parsable by scripts to allow integration with other systems (see section below).

It should be possible to edit the docs by hand in a simple text editor, but it would be nice to also be able to use GUI tools if desired.

Our 6MB of LaTeX docs are already hard to handle using a format which makes them even bigger does not help.

The new format should be as concise as possible.

#Doxygen param type python how to#

There has been much discussion about how to do this properly. DocBook and Doxygen) is a lot cleaner and more customizable.

Tex2RTF generates "old" HTML (similar to HTML4 but probably not compliant) and lots of other formats which were widely used 10-15 years ago, but not anymore (e.g.

Adding new features and even just keep it running requires too much time.

#Doxygen param type python upgrade#

wxWidgets developers cannot realistically upgrade and revise its code. Tex2RTF is not actively maintained and it contains various bugs.There is a utility in wxWidgets for doing this (HelpGen), but its far from ideal, and has to be maintained right alongside TeX2RTF. Everything in the LaTeX documentation has to be done by hand, while programs like Doxygen help out by doing the function headers etc.Nothing guarantees (or checks) that the documentation in the LaTeX files is consistent with the actual code.It can not be parsed by many standard LaTeX publication tools, and currently uses a custom in-house tool called TeX2RTF for publication, which means that for any new feature to be added to make documentation easier, it has to be added to TeX2RTF first. The LaTeX source is not real LaTeX, it's a specialized subset of it with some limitations.It would be useful to have a more structured format, since that would allow us to automatically extract more information from the documentation sources. This means the markup is only visual and doesn't tell us anything about the meaning of the information. The LaTeX source basically contains presentation markup only, not any semantic markup.The current LaTeX approach, while it works for creating HTML, PDF, and CHM documentation, has some shortcomings: 6 Comparison of BoostBook vs Custom Markup.3 Benefits of a Concise and Easy-to-Parse Semantic Markup.2 Requirements for a New System and Format.

I cannot find any specific documentation about the use of the :keyword identifier, but I can vouch that it is rendered correctly on P圜harm (and Spyder).īeta Was this translation helpful? Give feedback. and list all the keyword arguments in the one comment, or as I noted above to use, for example :keyword a: comment about parameter a. Then the only option is to have a docstring entry :param **kwargs. They are there in the docstring for people who view the raw docstring, but not rendered by the P圜harm editor. So the swig-generated comments about parameters a, b, and c do not get rendered to the P圜harm help window. In the example above the actual parameters of the Python function are '*args' and '**kwargs'. P圜harm and perhaps some other Python editors will not display the parameter comments when the named keywords are not ACTUAL parameters of the function. If *args or **kwargs are accepted, they should be listed as '*args' and '**kwargs'.Īnd it seems editors like P圜harm are enforcing this. The only documentation I can find that alludes to this is for the sphinx napoleon extension:īoth the numpy and google style documentation says: