Fix type confusion during downcastsing and add a test case showing how to extract an array from a dictionary.

[adamreichold]

Fixes #242

[adamreichold]

@davidhewitt @kngwyu I think there is a serious type confusion bug present here. The test added here first failed with

    def test_extract():
        x = np.arange(5)
        d = { "x": x }
>       np.testing.assert_almost_equal(extract(d), 10.0)
E       AssertionError: 
E       Arrays are not almost equal to 7 decimals
E        ACTUAL: 5e-323
E        DESIRED: 10.0

tests/test_ext.py:30: AssertionError
---------------------------------------------------------------------------------------------------------------------------- Captured stderr call ----------------------------------------------------------------------------------------------------------------------------
[examples/simple-extension/src/lib.rs:68] x.dtype() = dtype('int64')

which is surprising as the downcast to PyArray1<f64> should not have worked in the first place due to the dtype.

I think the problem is again that instances of PyArray<T, D> are considered the same type w.r.t. Python for all T, i.e. the macro invocation at

rust-numpy/src/array.rs

Lines 115 to 122 in 2da4787

	pyobject_native_type_info!(
	PyArray<T, D>,
	*npyffi::PY_ARRAY_API.get_type_object(npyffi::NpyTypes::PyArray_Type),
	Some("numpy"),
	#checkfunction=npyffi::PyArray_Check
	; T
	; D
	);

will imply calling the check function without the generic arguments via https://github.com/PyO3/pyo3/blob/2503a2dd5e9d8b703d3b9c6ce3ce12ce0126affe/src/types/mod.rs#L158 which in our case is npyffi::PyArray_Check which will therefore consider PyArray1<i32> and PyArray1<f64> to be the same type.

I tried to fix this by manually implementing PyTypeInfo and reusing the existing logic of the FromPyObject::extract which includes npyffi::PyArrayCheck but also checks element type and dimensionality.

[kngwyu]

Oh no!
@davidhewitt If we implement PyTypeInfo manually, should we simplify the macro in pyo3?

[davidhewitt]

Yikes, good find!

Now that numpy isn't using the generics for native_type_info I'm definitely tempted to refactor the macros in PyO3. However I don't think we need to rush to do this, because when we try to implement owned PyAny (maybe in 0.17, finally) then we'll need to write a new set of macros anyway. So might as well leave these ones as-is for now.

[adamreichold]

Now that numpy isn't using the generics for native_type_info I'm definitely tempted to refactor the macros in PyO3.

If rust-numpy is the only reason this macro supports generics, then I'd suggest removing as they are a bit of a foot gun. I don''t think it can be correctly implemented without access to the type arguments and their bounds. (Tricks like #checkfunction=Self::checkfunction works to get access to the types, but not to their bounds.)

Downstreams like us who do want to do this should go the manual route so they double-check everything. But then again, the macro itself is not really public documented API in the first place, isn't it?