@@ -54,7 +54,7 @@ Extending xarray
54
54
np.random.seed(123456 )
55
55
56
56
xarray is designed as a general purpose library, and hence tries to avoid
57
- including overly domain specific methods . But inevitably, the need for more
57
+ including overly domain specific functionality . But inevitably, the need for more
58
58
domain specific logic arises.
59
59
60
60
One standard solution to this problem is to subclass Dataset and/or DataArray to
@@ -69,7 +69,11 @@ task, even if most methods are only forwarding to xarray implementations.
69
69
70
70
__ https://github.com/pydata/xarray/issues/706
71
71
72
- To resolve this dilemma, xarray has the experimental
72
+ If you simply want the ability to call a function with the syntax of a
73
+ method call, then the builtin :py:meth: `~xarray.DataArray.pipe ` method (copied
74
+ from pandas) may suffice.
75
+
76
+ To resolve this issue for more complex cases, xarray has the
73
77
:py:func: `~xarray.register_dataset_accessor ` and
74
78
:py:func: `~xarray.register_dataarray_accessor ` decorators for adding custom
75
79
"accessors" on xarray objects. Here's how you might use these decorators to
@@ -90,14 +94,17 @@ defined that returns an instance of your class:
90
94
return GeoAccessor(self )
91
95
92
96
However, using the register accessor decorators is preferable to simply adding
93
- your own ad-hoc property (i.e., ``Dataset.geo = property(...) ``), for two
97
+ your own ad-hoc property (i.e., ``Dataset.geo = property(...) ``), for several
94
98
reasons:
95
99
96
- 1. It ensures that the name of your property does not conflict with any other
97
- attributes or methods.
100
+ 1. It ensures that the name of your property does not accidentally conflict with
101
+ any other attributes or methods (including other accessors) .
98
102
2. Instances of accessor object will be cached on the xarray object that creates
99
103
them. This means you can save state on them (e.g., to cache computed
100
104
properties).
105
+ 3. Using an accessor provides an implicit namespace for your custom
106
+ functionality that clearly identifies it as separate from built-in xarray
107
+ methods.
101
108
102
109
Back in an interactive IPython session, we can use these properties:
103
110
@@ -115,7 +122,9 @@ Back in an interactive IPython session, we can use these properties:
115
122
116
123
The intent here is that libraries that extend xarray could add such an accessor
117
124
to implement subclass specific functionality rather than using actual subclasses
118
- or patching in a large number of domain specific methods.
125
+ or patching in a large number of domain specific methods. For further reading
126
+ on ways to write new accessors and the philosophy behind the approach, see
127
+ :issue: `1080 `.
119
128
120
129
To help users keep things straight, please `let us know
121
130
<https://github.com/pydata/xarray/issues> `_ if you plan to write a new accessor
0 commit comments