final edits

Author: alimanfoo

_posts/2019-05-02-zarr-2.3-release.md

@@ -138,24 +138,39 @@ adapter](https://zarr.readthedocs.io/en/stable/api/n5.html#zarr.n5.N5Store)
 which allows reading and writing of data on disk in the N5
 format. 
 
-## Support of the buffer protocol
-
-The Python buffer protocol for those that are familiar is a specification for
-how to share large blocks of memory between different libraries without
-copying. This protocol has evolved over time from its original introduction in
-Python 2 and later revamped implementation added in Python 3 (with backports to
-Python 2.6 and 2.7). Due to the changes in its behavior from Python 2 to Python
-3 and what objects supported which implementation of the buffer protocol, it
-was a bit challenging to leverage effectively in Zarr. This despite the value
-of having zero-copy when storing data or performing filtering and compression.
-
-Thanks to some under-the-hood changes in Numcodecs 0.6 and Zarr 2.3, the buffer
-protocol is now cleanly supported for Python 2/3 in both libraries when working
-with data. In addition to improved memory handling and performance, this should
-make it easier for users developing their own stores, compressors, and filters
-to use with Zarr. Also it has cutdown on the amount of code specialized for
+
+## Support for the buffer protocol
+
+Zarr is intended to work efficiently across a range of different
+storage systems with different latencies and bandwidth, from cloud
+object stores to local disk and memory. In many of these settings,
+making efficient use of local memory, and avoiding memory copies
+wherever possible, can make a substantial difference to
+performance. This is particularly true within the
+[Numcodecs](http://numcodecs.rtfd.io) package, which is a companion to
+Zarr and provides implementations of compression and filter codecs
+such as Blosc and Zstandard. A key aspect of achieving fewer memory
+copies has been to leverage the Python buffer protocol.
+
+The [Python buffer
+protocol](https://docs.python.org/3/c-api/buffer.html) is a
+specification for how to share large blocks of memory between
+different libraries without copying. This protocol has evolved over
+time from its original introduction in Python 2 and later revamped
+implementation added in Python 3 (with backports to Python 2.6 and
+2.7). Due to the changes in its behavior from Python 2 to Python 3 and
+what objects supported which implementation of the buffer protocol, it
+was a bit challenging to leverage effectively in Zarr.
+
+Thanks to some under-the-hood changes in Zarr 2.3 and Numcodecs 0.6,
+the buffer protocol is now cleanly supported for Python 2/3 in both
+libraries when working with data. In addition to improved memory
+handling and performance, this should make it easier for users
+developing their own stores, compressors, and filters to use with
+Zarr. Also it has cutdown on the amount of code specialized for
 handling different Python versions.
 
+
 ## Future developments
 
 There is a growing community of interest around new approaches to
@@ -190,3 +205,16 @@ developments, keep an eye on the
 [zarr-specs](https://github.com/zarr-developers/zarr-specs) GitHub
 repositories, and please feel free to raise issues or add comments if
 you have any questions or ideas.
+
+
+## And finally... SciPy!
+
+If you're coming to SciPy this year, we're very pleased to be giving a
+talk on Zarr on [day 1 of the conference (Wednesday 10
+July)](https://www.eiseverywhere.com/ehome/381993). Several members of
+the Zarr community will be at the conference, and there are sprints
+going on after the conference in a number of related areas, including
+an Xarray sprint on the Saturday. Please do say hi or [drop us a
+comment on this
+issue](https://github.com/zarr-developers/zarr/issues/396) if you'd
+like to connect and discuss anything.