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

Matthias BUSSONNIER bussonniermatthias at gmail.com
Mon Nov 25 09:44:46 EST 2013


Le 25 nov. 2013 à 15:16, Sven Brauch a écrit :

> Hi!
> 
> 2013/11/25 Matthias BUSSONNIER <bussonniermatthias at gmail.com>:
>> It seem to work partially with numpy as
> That sounds cool, I'll check that out. Maybe I can also ask the ipython people.

Sure we'll be happy to help, Completer and introspection is just not a place were I feel comfortable.
You can either pitch in on IPython-dev or directly on github.

This :
https://github.com/ipython/ipython/wiki/IPEP-11%3A-Tab-Completion-System-Refactor
Might also be relevant, both to understand our current completion system and see what might be coming up.
People from Spyder also use IPython under the hood for completion IIRC, LightTable can also hook 
into IPython I guess.

I think one way this can be improved is using Python3 annotation to hint the type of the parameters
and or return value.
I think Jedi is able to parse this kind of information. 

Of course one solution could also be to uniformise  numpy  docstrings.

-- 
Matthias


>> I think "complex ndarray" is probably pretty good. It's unlike someone would
>> write ndarray if they didn't mean a NumPy array.
> It's good for a human. How would a script even know it's an ndarray?
> Of course this case is easy to cover, but there's lots and lots of
> ways the return type is specified in the docs; often something like
> "array_like" which is not an actual class, or "this or that if
> $condition is met" or various other forms. I tried to write a script
> which parses that, but it failed quite miserably.
> In many cases, return type is also clear from the docstring, but not
> mentioned in the proper format, e.g. here:
> http://docs.scipy.org/doc/numpy/reference/generated/numpy.fromfile.html#numpy.fromfile
> There you have zero chance to figure it out with a script imo,
> although it would be quite important.
> 
> To bring up another idea, might it be possible to observe a test suite
> and deduce types from there? I could possibly hook into cpython and
> catch function calls, and inspect the return and argument types from
> there. But I don't know enough about CPython's internals to judge
> whether that would give any useful results or not.
> 
> Greetings,
> 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/c4811a84/attachment.html>


More information about the SciPy-Dev mailing list