It should now pass all the tests, lets see what Travis thinks, and I think I have the logic pretty much figured out. Still missing tests and probably a rewrite of the docs.

There don't seem to be any specific tests for view, any recommendation on where to stick them?

@jaimefrio Needs a rebase.

Read thought it, and it makes sense, though there are still a couple lines I need to go over. I have some more conceptual questions/comments:

Does it often happen in real life that the minimal stride axis is not the first or last axis? What's an example of that?

Also, I am curious if anyone knows examples in the wild where it is useful to view using a different itemsize (eg np.zeros(3, 'p,p').view('p,p,p')). Even without this PR, understanding how that works is bit non-obvious, since the affected axis depends on the strides. For example,

>>> a = zeros((3,3), dtype='p,p')
>>> b = asfortranarray(a)
>>> a.view('p,p,p').shape
(3, 2)
>>> b.view('p,p,p').shape
(2, 3)

By the way, I looked into the history of the code which does this (in array_descr_set) ... it hasn't changed much from 2005, when it was cut+paste in from an SVN repository (so eariler history is lost).

I have rebased, and I think this should now pass all tests. Before anyone gets tempted to merge it:

1. There are no tests!
2. This mailing list post is the origin of me working on this.
3. Neither @njsmith nor @seberg were too happy about my fine disregard for the rules of taking views, there was quite some discussion on the mailing list. The only conclusion I get from re-reading that is that we did not find any behavior that made us all happy.

Not sure. Ian seems to have the proposal of adding dimensions for the view, which somewhat makes sense but I am not quite sure that the logic actually is very consistent with fractional size diffs and larger vs. smaller types.
Is it worth a shot to either deprecate Fortran order views, or introduce an order argument and switch it to C as default with a warning for now (currently I am not sure axis is sufficient, unless you allow multiple axes)?
Either of that would allow you to do anything you like pretty much in terms of generality, including even `order='K', without making things so general that nobody would understand the result when they suddenly have a transposed array.

2 comments:

First, in that list discussion it was suggested we could add an extra 'order' or 'axis' keyword arg to ndarray.view to resolve ambiguities in how to reshape.

What about having a shape argument instead? I like that because changing the shape of an ndarray is sort of like giving the same bytes a different interpretation, just like viewing with a dtype. This way the user could resolve ambiguity about which shape they want for the dtype change, and the expected shape is explicit in the code (easier to read).

>>> arr.view(shape=(2,3)) 
>>> a = zeros((20,1), dtype='i8')
>>> a.view(dtype='i4', shape=(40,1))
>>> a.view(dtype='i4', shape=(20,2))

Unlike reshape this would raise an error if the new shape is incompatible. This would actually be generally useful for people who want to reshape an array without possibility of getting a copy, eg the first two lines here could be replaced with the last

>>> a = myArrayCreator()
>>> a.shape = (2,3)

>>> a = myArrayCreator().view(shape=(2,3))

(and implementation in PyArray_View would be just like for dtype, it assigns to the attribute)

Second, I like this PR as is. (...maybe with corrections for size-1 axes).

It might be a little unintuitive but that's quickly fixed by a brief section in the docs about "views with different itemsizes", along with a big warning that you have to think carefully about memory layout if you want to change the itemsize. I think we should have a new section in the user guide on views (right before byteswapping), the last section of which could be something like this:

Views of different datatype itemsize 
------------------------------------

Taking a view which changes the itemsize (eg `np.zeros(2,'i4').view('i8')` ) is
possible but complicated since it depends on the memory layout of the array and
will change the shape of the array. In order to use such views sensibly you
must understand the array's memory layout (see
`arrays.ndarray.html#internal-memory-layout-of-an-ndarray`) and whether the
array is C-contiguous, Fortran-contiguous, or neither. 

When a view changes the itemsize of an array, numpy looks for the axis over
which the elements are contiguous in memory (this is equivalent to choosing the
axis whose stride is equal to the old itemsize) and allows the dtype change as
long as an integer number of items of the new itemsize would fit along that
axis, and resizes the shape at that axis accordingly. For C-contiguous arrays
this will be the last axis. Beware that, for example, transposed matrices
(`arr.T`) are not C-contiguous, but they can be made so with
`ascontiguousarray`.

Note that if there are dimensions of size 1 and the itemsize decreases it can
be ambiguous which axis should be resized. In this case it is recommended to
specify the desired shape as an argument to the view. By default numpy will
choose the leftmost such axis. [or something else?]

    >>> a = zeros((3,1), dtype='i8') 
    >>> a.view('i4').shape
    (3, 2)
    >>> b = a.view('i4', shape=(6, 1)) 
    >>> c = a.view('i4', shape=(3, 2))

Note that if the itemsize increases or if it changes by a fractional amount (eg
'i,i,i' to 'i,i') there can be no dimensions of size 1, and the choice of 
contiguous axis will be unambiguous.

☔ The latest upstream changes (presumably #6208) made this pull request unmergeable. Please resolve the merge conflicts.

@jaimefrio Needs rebase.

Should we bring views of non-contiguous arrays up again on the mailing list?

This seems somewhat interesting, but after looking at it and considering that it was still a work in progress, it seems to me that the best thing may be to close it until it is brought up again (with more use-cases maybe). Especially, since it does not seem we were able to quite hash out the desired behaviour and some of it is pretty surprising!

EDIT: If anyone disagrees, please just comment.