This (base_dtype, new_dtype) way of specifying dtypes is discouraged according to http://docs.scipy.org/doc/numpy-dev/reference/arrays.dtypes.html#arrays-dtypes but still valid. So should indeed be fixed.

There are really too many ways to create dtypes.....

Reply by Andrew Collette, author of h5py, on the numpy discussion mailing list on 13 Dec 22:57:

"

the following code using np.object_ data types works with numpy 1.5.1
but fails with 1.6.2. Is this intended or a regression? Other data
types, np.float64 for example, seem to work.

I am also seeing this problem; there was a change to how string types
are handled in h5py 2.1.0 which triggers this bug. It's a serious
inconvenience, as people can't do e.g. np.copy()
any more.

These downstream issues could be related:

http://code.google.com/p/h5py/issues/detail?id=217

Yes, this seems to be the cause of issue 217.
"

@cgohlke, could you please write a test for this too?

I am not very familiar with this part of numpy. But if Ralf or others are giving the patch +1, I am ok to merge this to 1.7. It seems simple enough that hopefully things will not break.

@cgohlke either that, or maybe numpy/core/tests/test_multiarray.py.

@rgommers, are you +1 with this patch? All tests pass (the only failure is the old python 3.1 which was removed from Travis and we fixed it in our .travis.yml in the meantime) and it looks ok to me.

Backported in #2859.

@certik looks reasonable, but I'm not familiar with this code either. @mwiebe, @charris could one of you have a quick look?

I'm not familiar with that code either, but it looks like the patch makes the object type special, just as datetime and timedelta are. That 'feels' like it might be the right thing but I can't say much more without a longer look at the code. @cgohlke It might be nice to have a comment in the code explaining the reason. That said, I tend to trust Christoph's judgement in these things.

@cgohlke, or you can explain your reasoning in the commit log. For example to me, as somebody who is not familiar with this part of the code, I have no idea what your patch does, or is intending to do. All I can see is that it fixes some problem with astype().

The Travis failure is due to the missing Python 3.1

@cgohlke I would like to release rc1 today or early tomorrow. If you could please address the reviews, let's get it in and release. If not, then it will have to wait for rc2, or go into 1.8.

Looking at the code some, this patch is definitely not a complete fix for whatever's going on here... there are only two call sites for get_cast_transfer_function, and one of them calls it specifically to retrieve a cast function in case the src and dst dtypes have different type nums (dtype_transfer.c:3638)! So either the check in get_cast_transfer_function is totally wrong, or the code that calls it is.

I suspect the correct fix is to just delete the check and error message entirely. This function is just responsible for fixing up alignment/byte-order and delegating to the lower-level functions that actually know how to do casting for different types, so having a check on the types here is reaaally fishy.

Well, stuck up the just-delete-the-check patch as #2863.