New accessor for a biomechanics open source library
See original GitHub issueHello and first of all, thank you for xarray.
With a colleague, we created pyomeca
which is a Python library specialized in biomechanical data processing. Most of the data is multidimensional and so we have reimplemented by hand some functionality to access labels, etc. Except Xarray does it much better.
I am rewriting the entire library using xarray. motion
reimplements the pyomeca functions with an accessor for xarray.
I have some questions about the architecture you recommend for a xarray-based library.
In pyomeca, I have three classes (RotoTrans
, Markers3d
and Analogs3d
) with each having very specific functions.
I have two possible solutions to implement them with xarray: (1) write an accessor for each class or (2) inherit from DataArray, e.g:
import xarray
Rototrans class (xarray.DataArray):
pass
According to your documentation, the accesor is the recommended method. However, for most functions, I need a three-dimensional table with specific dimensions ([axis, channels, time_frame]
) and the accessor does not allow to perform these checks when creating the DataArray. At the same time, the second solution forces me to inherit a basic function that allows me to access the functions common to all classes
import xarray
class BaseArray(xarray.DataArray):
def fct():
pass
class Rototrans(Base):
pass
Do you have any design recommendations?
Issue Analytics
- State:
- Created 4 years ago
- Comments:6 (6 by maintainers)
Top GitHub Comments
What about simply wrapping xarray objects internally in your classes, along with utilities for converting to/from xarray objects? When users want to do domain specific stuff they can use your objects, and when they want to do something generic with xarray they can convert by calling a method like
to_xarray
.+1 to shoyer - encapsulation is by far the easiest approach.
The accessor
__init__
method will be invoked by xarray the first time you invokearray.foo
.Note, however, that it is not recommended to put expensive calculations in it, because the object will possibly be destroyed and reinitialised every time the array is transformed - or in other words, anything that is not a read-only method/property or a cell update.
I emphasized possibly because some transforms may not destroy and recreate your accessor instance, thus potentially causing it to be in a state that is incoherent with the attached xarray object. Every time you invoke a method, you should verify that whatever assumptions you relied upon to generate the state are still valid.