[SciPy-Dev] Supporting numpy/scipy in an IDE

Marmaduke Woodman marmaduke.woodman at univ-amu.fr
Mon Nov 25 04:55:32 EST 2013


Hi

If by website you mean the usual NumPy SciPy docs [1], this is generated by
Sphinx,
which seems to identify nicely the arguments and returns which are written
out as
RST in the docstring format [2]

You could adapt Sphinx's parsing/building classes to get "direct" access to
the docstring info?

cheers,
Marmaduke

[1] e.g. http://docs.scipy.org/doc/numpy/reference/generated/numpy.load.html
[2]
https://github.com/numpy/numpy/blob/master/doc/HOWTO_DOCUMENT.rst.txt#id4


On Mon, Nov 25, 2013 at 9:01 AM, Sven Brauch <svenbrauch at googlemail.com>wrote:

> Hi!
>
> I'm writing a plugin for an IDE which does things like code completion on
> Python code. Usually, it gets the necessary information from static
> analysis
> of Python code (which works fairly well for many libraries); however, in
> the
> case of numpy, this obviously does not work at all because numpy is not
> written in pure Python.
>
> For improving numpy support, I would especially need the following
> information:
>
>  * What are the arguments of a particular function? Python's inspect won't
>    tell me; it seems like this information is just available in the prosa
>    text docstring. The website has it in a somewhat machine-readable way,
>    is there a method to get the actual list of parameters which does not
>    involve parsing that? Or is the table on the website based on parsing
>    the docstring?
>
>  * What kind of object does a function return? Of course this is not always
>    well-defined, but in most cases it is. This information, too, only
> seems to
>    be available in the prosa docstrings, if at all -- and different from
> the
>    argument specification, it's usually just mentioned somewhere in a not
>    even remotely machine-readable form.
>
> My question is thus: Do you see any reasonable (automatable) way to extract
> this information from any resource (code, docs, ...)? I think having this
> information in a machine-readable form would also be beneficial for various
> other projects.
>
> I'm happy about every suggestion. I dislike solutions based on inspecting
> things at runtime; it is scary to run code a user types into the editor,
> and
> it will also be slow in a variety of cases.
>
> Best regards,
> Sven
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20131125/b5d7f0d8/attachment.html>


More information about the SciPy-Dev mailing list