Thanks, David. Very insightful.
Needless to say, I don’t like the idea of forcing VTK users to use a specific API to interface with numpy or anything else.
To dig a bit into the specific details of why PyVista broke is that its subclassing is designed such that the attributes that they define do not override the superclass’ attributes. This is due to the use of multiple inheritance and the order of inheritance. The mixins that they are using are inherited from after the VTK classes and hence do not override attributes of the same name. I would argue that this is something that should fixed irrespective of the data model changes. VTK should be allowed to define a property or a method without worrying about conflicts with subclasses. On the other hand, Vedo does not have this problem even though it also overrides methods. So I don’t believe that VTK is forcing any API on anyone.
In terms of the use of this API spreading, I expect that it will be. There is an algorithms module that depends on this API heavily for example. That’s because it uses numpy and mpi4py to do bunch of things. I don’t think that it is fair to say that VTK cannot use numpy in its implementation.
It’s also worth repeating that pure Python-based projects (vedo, PyVista, etc.) generally have an advantage of rapid development and relatively low barrier to entry. VTK has a high barrier to entry and slow iterations (for those who aren’t using source builds from the master branch). This, I feel, is why VTK’s numpy interface has had only intermittent development and low adoption.
+1