@@ -193,20 +193,22 @@ good idea to instead receive a 1-dimensional memory view, e.g.
193
193
def process_byte_data(unsigned char[:] data):
194
194
length = data.shape[0]
195
195
first_byte = data[0]
196
- byte_slice = data[1:-1]
196
+ slice_view = data[1:-1]
197
197
...
198
198
199
199
Cython's memory views are described in more detail in
200
- :doc: `../userguide/memoryviews `,
201
- but the above example already shows most of the relevant functionality
202
- for 1-dimensional byte views. They allow for efficient processing of
203
- arrays and accept anything that can unpack itself into a byte buffer,
204
- without intermediate copying. The processed content can finally be
205
- returned in the memory view itself (or a slice of it), but it is
206
- often better to copy the data back into a :obj: `bytes ` or :obj: `bytearray `
207
- object, especially when only a small slice is returned (as the memoryview
208
- would otherwise keep the entire original buffer alive). This can simply
209
- be done as follows::
200
+ :doc: `../userguide/memoryviews `, but the above example already shows
201
+ most of the relevant functionality for 1-dimensional byte views. They
202
+ allow for efficient processing of arrays and accept anything that can
203
+ unpack itself into a byte buffer, without intermediate copying. The
204
+ processed content can finally be returned in the memory view itself
205
+ (or a slice of it), but it is often better to copy the data back into
206
+ a flat and simple :obj: `bytes ` or :obj: `bytearray ` object, especially
207
+ when only a small slice is returned. Since memoryviews do not copy the
208
+ data, they would otherwise keep the entire original buffer alive. The
209
+ general idea here is to be liberal with input by accepting any kind of
210
+ byte buffer, but strict with output by returning a simple, well adapted
211
+ object. This can simply be done as follows::
210
212
211
213
def process_byte_data(unsigned char[:] data):
212
214
# ... process the data
0 commit comments