Fix get_array return type

[akaszynski]

Problem

The documentation for DataSetAttributes.get_array, states that:

Returns
-------
pyvista.pyvista_ndarray or vtkDataArray
    Returns a :class:`pyvista.pyvista_ndarray` if the
    underlying array is either a ``vtk.vtkDataArray`` or
    ``vtk.vtkStringArray``.  Otherwise, returns a
    ``vtk.vtkAbstractArray``.

However, in neither our testing or documentation build do we ever return a vtk.vtkAbstractArray. Moreover, since a vtk.vtkAbstractArray can't be directly instanciated, it's not possible to set this array either. It's also unclear why this was added in the first place.

Solution

Simply remove this branch statement and clean up the return type and docstring.

It's not hit in any of our tests, and this simplifies our API such that we always return a pyvista.pyvista_ndarray from DataSetAttributes.get_array. In the unlikely case where an edge case arises, we can add support for that in a follow-up PR.

[adeak]

LGTM (with the caveat that we still don't know why this was here).

[codecov]

Codecov Report

Merging #2782 (632fd1e) into main (d5c89f1) will increase coverage by 0.01%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main    #2782      +/-   ##
==========================================
+ Coverage   93.86%   93.88%   +0.01%     
==========================================
  Files          76       76              
  Lines       16230    16255      +25     
==========================================
+ Hits        15235    15261      +26     
+ Misses        995      994       -1     

[akaszynski]

LGTM (with the caveat that we still don't know why this was here).

Since we should always be returning a "wrapped" array, I'd prefer just handing a vtkAbstractArray pyvista.pyvista_ndarray or raising a TypeError (or potentially a custom not supported error). However, I can't even create an example to return a vtkAbstractArray and therefore can't even come up with a fictitious edge case.

Again @JevinJ, if you could weigh in here as to why we could either preserve or handle this branch better.

[adeak]

Good point:

>>> pv._vtk.vtkAbstractArray()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: this is an abstract class and cannot be instantiated

So it's very much abstract indeed, and there's no chance to find an object the type of which is exactly vtkAbstractArray. I think this is good to go.

[JevinJ]

So long ago, but I believe this was for an edge case on the vtk side or the user doing something weird. If that's not normal then I guess that makes sense to remove.