machinalis / mypy-data Goto Github PK

Getting a scalar from a numpy array does not seem to be supported.

import numpy
b : float = float(numpy.array(1))

with mypy gets the error:

error: Argument 1 to "float" has incompatible type "ndarray[Any]"; expected "Union[SupportsFloat, str, bytes]"

The current signature for ndarray.all includes the keepdims argument, which is not present in the documentation (it probably came from following numpy.all specification).

We renamed np.int to np.int_ to avoid ambiguity in the module when referring to int. However this breaks code doing things like some_array.as_type(np.int)

I've grown very interested in obtaining and expanding numpy stubs.

However, when it comes to typed ndarrays, I've come to this issue

def a_function(x: np.ndarray[np.float32]) -> None:
    print('Foo')

is valid for mypy, however the python3 interpreter fails (logically. Here in interpreter, same for type hints in modules.).

In [4]: np.ndarray[np.float32]
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-4-d3b20ca13ba6> in <module>()
----> 1 np.ndarray[np.float32]

TypeError: 'type' object is not subscriptable

Question is, how to circumvent this problem ? a typing package style protocol requiring arguments dtype, shape, etc... ?

The current definition should probably use ShapeType as an index, and _S as value. To avoid the ambiguity of the 1 argument/2 argument version, an @overload definition could be better.

Current versions of __iadd__, __imul__ etc return None, while they should return the same type as __mul__

Some function arguments accept only objects with a buffer interface as described by PEP-3118. That's a C level API and it's not backed by any Python methods so it's hard to describe in mypy, so those arguments are currently described as Any

This need some support from python; see some related discussions at:

http://permalink.gmane.org/gmane.comp.python.devel/156411
http://bugs.python.org/issue27501

Matrices have a special wapper type in numpy which isn't implemented yet: http://docs.scipy.org/doc/numpy/reference/generated/numpy.matrix.html#numpy.matrix

Many users use for example numpy.dot(a, b) instead of a.dot(b). Having the top level versions of those functions should cover more use cases

When I use mypy with these stubs (python 3.6, MacOS) I get this (cryptic) message:

stubs/numpy/__init__.pyi:48: error: Class numpy.flatiter has abstract attributes "__next__"
stubs/numpy/__init__.pyi:48: note: If it is meant to be abstract, add 'abc.ABCMeta' as an explicit metaclass

I'm afraid I don't know what this means; I suspect it has to do with the use of type variables, but...

Hi,
Is this project still alive?

I noticed that there were some errors (e.g., flatiter does not specify __next__ etc.). Should we submit the fixes here as a pull request or should we fork the repo and develop it further ourselves?

It seems a bit unclear to me how to properly annotate functions that expect an ndarray. Many ndarray functions (e.g. flatten) return _ArrayLike which is then not recognized to be an ndarray. I guess I can't and shouldn't use _ArrayLike in my own annotations. Is this currently not supported properly by mypy or do I have to do this differently?
Btw., the numpy docs actually specify the return type of e.g. flatten to be ndarray, not "array_like".

It would be great if you could add your numpy stubs to Typeshed.

https://github.com/python/typeshed/tree/master/stdlib/2and3

You have already written the most useful parts of the numpy stub and could just use stubgen to complete the stub file...

https://github.com/ashleyh/mypy-stubgen

Currently they accept anything. Being stricter needs some care because both accept setting and converting scalars, arrays, or python values, and they also can accept python objects, arrays, slices, etc as keys.

Functions that accept file objects (Currently: ndarray.tofile and numpy.fromfile) should have arguments declared as typing.io.IO.

This is blocked by python/mypy#1462

ndarray.ctypes returns an object with implementation information, that is still not covered by our stubs

I have this in some code:

logarr = np.fromiter(loglist, np.longdouble, -1)

which causes problems when using the numpy stubs:

simple_model_kl.py:20: error: Module has no attribute "longdouble"

I think it's correct to just add

class longdouble(floating): ...

to __init__.pyi

Could you please provide a license for you code? Thank you!

Some functions like:

    def all(self, axis: AxesType=None, out: '_ArrayLike[_U]'=None, keepdims: bool=False) -> Union['_ArrayLike[_U]', '_ArrayLike[bool]']: ...

Should actually be defined as:

    @overload
    def all(self, axis: AxesType=None, keepdims: bool=False) -> '_ArrayLike[_S]: ...
    @overload
    def all(self, axis: AxesType=None, keepdims: bool=False, out: '_ArrayLike[_U]') -> '_ArrayLike[_U]: ...

But that's not working correctly because of python/mypy#1907

Many functions accept a dtype argument for type conversions. That argument can be an instance of numpy.dtype or anything that can be converted to those by the numpy.dtype constructor. That includes:

• python types (like, int, float, str, MyCustomClass)
• lists of field descriptions like [('f1', np.uint), ('f2', np.int32)]
• strings with standard type names (int32), or dtype descriptions like <i2.
• dicts with fields/formats of fields

More details available at http://docs.scipy.org/doc/numpy/reference/generated/numpy.dtype.html

Currently, those arguments are typed inconsistently as Any, object, or DtypeType which covers only the first case. The fix for this should probably cover:

1. Giving all those arguments a DtypeSpec type
2. change the numpy.dtype signature to accept a DtypeSpec argument
3. Make DtypeSpec as close as possible to the description above.

For item 3, it's not necessary to cover everything that's possible but it should cover the most frequent uses.

I'm getting an error when I try to iterate over an numpy array:

error: Iterable expected

Do we need the main class to also inherit Iterable?

As a NumPy developer and user, I would love to see this happen. I can't promise I'll have the time to make this happen on my own, but I certainly am willing to help anyone with questions about the process.

Step 1 would be to add a license to this repository, preferably 3-clause BSD like NumPy.