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

Marmaduke Woodman marmaduke.woodman at univ-amu.fr
Mon Nov 25 05:24:41 EST 2013


I think "complex ndarray" is probably pretty good. It's unlike someone
would write ndarray if they didn't mean a NumPy array.

So, already you could complete .shape, .mean, etc. which is pretty good.
Knowing it's complex, you complete .imag, .real, no?

The existence of certain methods, or not, doesn't depend on whether it's
complex64 or complex128 (and arguably shouldn't), so I would consider this
a win.

I realize it wouldn't be scalable if you have 100s of types with wildly
different methods etc.




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

> Hi!
>
> On Monday 25 November 2013 10:55:32 Marmaduke Woodman wrote:
> > You could adapt Sphinx's parsing/building classes to get "direct" access
> to
> > the docstring info?
> Hmm, yes, for the argument count and names that would work. But look at the
> types, e.g. in [1]: "out: complex ndarray" is not really machine-readable.
> I
> would need the actual type it returns, optimally the exact type (which
> module
> it is from etc.) but at least the class name.
>
> For the arguments the types are not that important, but having the return
> types is really essential information (otherwise, if the user writes a =
> numpy.fft.fft(...) and then requests code-completion for a, I can do
> nothing).
>
> Best regards,
> Sven
>
> ______________
> [1]
>
> http://docs.scipy.org/doc/numpy/reference/generated/numpy.fft.fft.html#numpy.fft.fft
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20131125/d2abb0e8/attachment.html>


More information about the SciPy-Dev mailing list