Skip to content

Commit af6e205

Browse files
committedJan 26, 2014
clarify memory view section in string processing docs
1 parent 800bbe4 commit af6e205

File tree

1 file changed

+13
-11
lines changed

1 file changed

+13
-11
lines changed
 

‎docs/src/tutorial/strings.rst

+13-11
Original file line numberDiff line numberDiff line change
@@ -193,20 +193,22 @@ good idea to instead receive a 1-dimensional memory view, e.g.
193193
def process_byte_data(unsigned char[:] data):
194194
length = data.shape[0]
195195
first_byte = data[0]
196-
byte_slice = data[1:-1]
196+
slice_view = data[1:-1]
197197
...
198198

199199
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::
210212

211213
def process_byte_data(unsigned char[:] data):
212214
# ... process the data

0 commit comments

Comments
 (0)
Please sign in to comment.