chore: codespell (#857)

Author: schwehr

README.md

@@ -143,7 +143,7 @@ the overall project and vision:
 ```
 
 Our [SciPy paper](https://proceedings.scipy.org/articles/NRPV2311), detailing
-the motivation and approach behind Jupyter Widget ecosystem compatability:
+the motivation and approach behind Jupyter Widget ecosystem compatibility:
 
 ```bibtex
 @inproceedings{manz2024notebooks,

anywidget/_descriptor.py

@@ -97,7 +97,7 @@ def open_comm(
     )
 
 
-# cache of comms: mapp of id(obj) -> Comm.
+# cache of comms: map of id(obj) -> Comm.
 # we use id(obj) rather than WeakKeyDictionary because we can't assume that the
 # object has a __hash__ method
 _COMMS: dict[int, comm.base_comm.BaseComm] = {}
@@ -106,7 +106,7 @@ def open_comm(
 def _get_or_create_comm(
     obj: object, get_state: Callable[[], dict]
 ) -> comm.base_comm.BaseComm:
-    """Get or create a communcation channel for a given object.
+    """Get or create a communication channel for a given object.
 
     Comms are cached by object id, so that if the same object is used in multiple
     places, the same comm will be used. Comms are deleted when the object is garbage
@@ -371,7 +371,7 @@ def send_state(self, include: str | Iterable[str] | None = None) -> None:
         state = {**self._get_state(obj, include=include), **self._extra_state}
         if include is not None:
             # ensure that we only send the keys that were requested
-            # incase the state getter returned extra keys
+            # in case the state getter returned extra keys
             state = {k: v for k, v in state.items() if k in include}
 
         if not state:

anywidget/widget.py

@@ -66,7 +66,7 @@ def __init_subclass__(cls, **kwargs: dict) -> None:
         """Coerces _esm and _css to FileContents if they are files."""
         super().__init_subclass__(**kwargs)
         for key in (_ESM_KEY, _CSS_KEY) & cls.__dict__.keys():
-            # TODO(manzt): Upgrate to := when we drop Python 3.7
+            # TODO(manzt): Upgrade to := when we drop Python 3.7
             # https://github.com/manzt/anywidget/pull/167
             file_contents = try_file_contents(getattr(cls, key))
             if file_contents:

docs/astro.config.js

@@ -37,7 +37,7 @@ export default defineConfig({
 				applyBaseStyles: false,
 			},
 		}),
-		// Suports components in markdown
+		// Supports components in markdown
 		mdx(),
 		sitemap(),
 	],

docs/src/components/Footer/AvatarList.astro

@@ -111,7 +111,7 @@ async function removeDupsAndFindCoAuthors(arr: Commit[]) {
 		users.forEach((user) => map.set(email, user));
 	}
 
-	// finally dedupe by user id (incase separate emails for same user)
+	// finally dedupe by user id (in case separate emails for same user)
 	let deduped = new Map<string, User>();
 	for (let [_, user] of map) {
 		deduped.set(user.id, user);

docs/src/pages/blog/a-year-with-anywidget.md

@@ -14,7 +14,7 @@ image:
 > [Discord](https://discord.gg/W5h4vPMbDQ) 🐣
 
 _TL;DR: **anywidget** v0.9 introduces `initialize` and `render`
-<a class="underline" href="#introducing-widget-lifecycle-hooks">lifecyle
+<a class="underline" href="#introducing-widget-lifecycle-hooks">lifecycle
 hooks</a> to allow greater control of front-end widget behavior_. _The preferred
 way to define widgets is now with a `default` object export:_
 
@@ -41,7 +41,7 @@ This update also requires developers to opt-in to
 [live development features](/blog/anywidget-02#native-hot-module-replacement-hmr),
 reducing some minor production issues for widgets.
 
-### Mimimizing Friction in Jupyter Front Ends
+### Minimizing Friction in Jupyter Front Ends
 
 **anywidget** aims to make creating and sharing Jupyter Widgets as simple as
 possible. We expose a narrower set of web-standard APIs, compared to traditional
@@ -64,7 +64,7 @@ stage would be very challenging for traditional Jupyter Widgets, **anywidget**
 can standardize certain aspects to make widget development less error-prone and
 more accessible.
 
-Despite these goals, serveral several community members highlighted specific
+Despite these goals, several several community members highlighted specific
 instances where **anywidget**'s existing API was too restrictive
 ([#266](https://github.com/manzt/anywidget/issues/266),
 [#388](https://github.com/manzt/anywidget/issues/388)), prompting us to
@@ -83,7 +83,7 @@ there are two distinct steps in a widget's lifetime:
 - _View Rendering_: Each notebook cell displaying the widget renders an
   independent view based on the model's current state.
 
-![The main parts of the widget lifecyle, including model initialization and view rendering](/widget-lifecycle.png)
+![The main parts of the widget lifecycle, including model initialization and view rendering](/widget-lifecycle.png)
 
 In **anywidget**, _view rendering_ logic is defined with `render`, but
 historically _model initialization_ was handled implicitly. While this

docs/src/pages/blog/anywidget-02.md

@@ -91,7 +91,7 @@ and **anywidget** will automatically read the file contents from disk for you.
 
 Now for the magic 🪄. Passing a file path not only offers a convenience to
 loading your front-end code, but also **opts in to anywidget's native HMR
-<u>during developement</u>.** **anywidget** will start listening for
+<u>during development</u>.** **anywidget** will start listening for
 modifications to the referenced files and instantly apply changes to the
 front-end, offering an integrated development experience within Jupyter like
 never before.
@@ -159,7 +159,7 @@ function render({ model, el }) {
 export default { render };
 ```
 
-The `import("@anywidget/types").Render<Model>` utilty strictly types the
+The `import("@anywidget/types").Render<Model>` utility strictly types the
 `render` function such that `model.get` and `model.set` are typed based on the
 user-defined `Model`.
 

docs/src/pages/blog/introducing-anywidget.mdx

@@ -472,7 +472,7 @@ with the `sync=True` metadata – just like regular Jupyter Widgets!
 #### Two-Way Data Binding
 
 The `ExampleWidget` demonstrates simple one-way data binding from the Python kernel
-to front-end view. This example is slightly more sophisicated and synchronizes the
+to front-end view. This example is slightly more sophisticated and synchronizes the
 model state between the widget front end and the Python kernel (i.e., two-way data binding).
 
 The `render` function creates a `button` element and registers an event handler

docs/src/pages/en/community.mdx

@@ -1,6 +1,6 @@
 ---
 title: "Community"
-discription: "Open-source projects built with anywidget"
+description: "Open-source projects built with anywidget"
 layout: "../../layouts/MainLayout.astro"
 image:
   {

docs/src/pages/en/getting-started.mdx

@@ -153,7 +153,7 @@ allowing real-time updates to your widget during development (below).
 
 ## Watch & Learn
 
-This video provides a detailed exploration of **anywidget** fundementals,
+This video provides a detailed exploration of **anywidget** fundamentals,
 including synchronizing Python and JavaScript state, binary data, animations,
 and publishing a package on PyPI.