You can't reassign the array object's __class__, and you can't modify the array type itself, so I think modifying the internal b_length field of the object is a confused result. 

Even if you ignore this confusion, it's still not as simple as using the size in bytes as the length. That's what b_size is for, after all. The array length is the new size divided by the element size, which you can get from PyType_stgdict(dict->proto)->size. Also, you'd have to ensure it's only updating b_length for arrays, i.e. ArrayObject_Check(obj), since it makes no sense to modify the length of a simple type, struct, union, or [function] pointer.

However, I don't think this result is worth the confusion. ctypes buffers can grow, but arrays have a fixed size by design. There are already ways to access a resized buffer. For example, you can use the from_buffer method to create an instance of a new array type that has the desired length, or you can dereference a pointer for the new array type. So I'm inclined to close this issue as "not a bug".

Note: 
Be careful when resizing buffers that are shared across objects. Say you resize array "a" and share it as array "b" using from_buffer or a pointer dereference. Then later you resize "a" again. The underlying realloc might change the base address of the buffer, while "b" still uses the old address. For example:

    >>> a = (ctypes.c_int * 5)(*range(5))
    >>> ctypes.resize(a, 4 * 10)
    >>> b = ctypes.POINTER(ctypes.c_int * 10)(a)[0]
    >>> ctypes.addressof(a)
    20136704
    >>> ctypes.addressof(b)
    20136704
    >>> b._b_needsfree_ # b doesn't own the buffer
    0
    >>> b[:] # the reallocation is not zeroed
    [0, 1, 2, 3, 4, 0, 0, 32736, 48, 0]

Here's the problem to keep in mind:

    >>> ctypes.resize(a, 4 * 1000)
    >>> ctypes.addressof(a)
    22077952
    >>> ctypes.addressof(b)
    20136704
    >>> b[:] # garbage; maybe a segfault
    [1771815800, 32736, 1633841761, 540763495, 1652121965,
     543236197, 1718052211, 1953264993, 10, 0]