Add .view() method for NumPy scalars

[esc]

This implements and fixes #3763

[sklam]

We will need to differentiate between numpy scalar and regular scalars that do not have the .view. Like:

x = 1
x.view(...) # invalid
np.int32(x).view(...) # valid

[sklam]

I wonder what is the status of .view on numpy scalar types. help(np.int32.view) shows:

view(...) method of numpy.int32 instance
    Not implemented (virtual attribute)

[esc]

@sklam should we implement view for regular scalars too?

[sklam]

@esc, the problem is that numba treat numpy scalar type and regular scalar type in the same way. So you have already implemented .view for regular scalar. But that will not work for regular python.

[esc]

Travis failed, because job exceeded timeout, restarting and keeping fingers crossed.

[esc]

@sklam is there anything else I might be able to code up for this? I don't think we should add a view method to regular Python types.

[esc]

Seems like it exceeded the time-limit again. Asking Travis-CI people if they can increase the timeout for Numba builds for us.

[seibert]

the Travis CI builds are redundant to the Azure builds at this point. Should we just drop them?

[esc]

@seibert it may really be worth considering.

[esc]

Looks like this is failing for Python 2.7

[esc]

Perhaps some sort of ascii vs. unicode issue, certainly does smell like it.

[stuartarchibald]

Unicode (unicode_type) is not supported on Py27 which is the root cause of the problems in CI, am wondering if a better error message could be raised (not for this PR though).

[esc]

So I updated the tests and they pass locally on 2.7. I hope they will pass CI too. @stuartarchibald @sklam is there any other types where you suggest I test them? int8 -> uint8 perhaps? Also, probably worth documenting that only Numpy scalars are supported and that they need to be initialized within the jitted function. Thoughts on where to drop this?

Two side quests so far:

• consider turning off TravisCI
• better errors on 2.7 for unsupported unicode stuffs.

[esc]

@stuartarchibald, actually, I think that raise statement can never be reached. Using overload_method means that the view is only available for integer and floating point types. Any other type will lead to something like: Unknown attribute 'view' of type complex128 with complex128 being the type. Do you agree? If so, it probably makes sense to remove it.

[stuartarchibald]

As the intrinsic is a function it could well be reused, but is only likely to be by developers, given that the implementation returned could be invalid in the case of simply removing the exception I'm inclined to leave it in or replace it with assert 0, 'unreachable'. The intrinsic function could also be moved to numba.unsafe.number or something as it is a useful piece of functionality.

[svenrahmann]

This implements exactly what I was looking for. Thank you.

[esc]

@svenrahmann thanks for the feedback, happy to hear it! 🎉

[esc]

CI revealed some tests that should be skipped on non-64 bit systems.

[esc]

All green and ready for review.

[stuartarchibald]

Thanks for the PR. This in general seems good and does what is expected. I've made a few comments, once resolved I'll re-review with view to merge. Thanks again!

[stuartarchibald]

Thanks for the fixes, couple more things to resolve and this can be marked for merge.

[esc]

Thanks for all the feedback, pushing fixes now.

[stuartarchibald]

Thanks for your persistence in getting this to work. This looks good :)

[stuartarchibald]

Pending CI pass, this can be marked for merge.

[esc]

😁

[esc]

Travis had a timeout again connecting to anaconda.org restarted the build.