diff --git a/crates/processing_pyo3/examples/animated_mesh.py b/crates/processing_pyo3/examples/animated_mesh.py
index 829f014..bdf87e0 100644
--- a/crates/processing_pyo3/examples/animated_mesh.py
+++ b/crates/processing_pyo3/examples/animated_mesh.py
@@ -4,7 +4,7 @@
 geometry = None
 grid_size = 20 
 spacing = 10.0
-offset = (grid_size * spacing) / 2.0;
+offset = (grid_size * spacing) / 2.0
 time = 0.0
 
 def setup():
diff --git a/docs/principles.md b/docs/principles.md
index b067c46..785f60b 100644
--- a/docs/principles.md
+++ b/docs/principles.md
@@ -83,7 +83,7 @@ user-facing API via an overload.
 We never return pointers to data that lives in libprocessing. Because we use the ECS to manage Rust data, where longer
 lifetimes are necessary we return an `Entity` id, which can be returned to the user as a `u64` containing both the index
 and generation of the ECS entity. Any data not representing an API-level object should be returned on the stack and
-where an allocation is necessary (e.g. buffers for pixel data), it's the responsibility of the consumer to allocate a
+where an allocation is necessary (e.g. buffers for pixel data), it's the responsibility of the consumer to allocate and
 provide the pointer to the requisite allocation.
 
 API-level objects should wrap ids and they should never be exposed to the user as a first-class concept. All data which