fix: typos in guide/docs (#5182)

Author: jessekrubin

guide/src/class.md

@@ -55,7 +55,7 @@ enum HttpResponse {
 }
 
 // PyO3 also supports enums with Struct and Tuple variants
-// These complex enums have sligtly different behavior from the simple enums above
+// These complex enums have slightly different behavior from the simple enums above
 // They are meant to work with instance checks and match statement patterns
 // The variants can be mixed and matched
 // Struct variants have named fields while tuple enums generate generic names for fields in order _0, _1, _2, ...
@@ -825,7 +825,7 @@ impl MyClass {
 
 ## Classes as function arguments
 
-Free functions defined using `#[pyfunction]` interact with classes through the same mechanisms as the self parameters of instance methods, i.e. they can take GIL-bound references, GIL-bound reference wrappers or GIL-indepedent references:
+Free functions defined using `#[pyfunction]` interact with classes through the same mechanisms as the self parameters of instance methods, i.e. they can take GIL-bound references, GIL-bound reference wrappers or GIL-independent references:
 
 ```rust,no_run
 # #![allow(dead_code)]
@@ -857,7 +857,7 @@ fn increment_then_print_field(my_class: &Bound<'_, MyClass>) {
     println!("{}", my_class.borrow().my_field);
 }
 
-// Take a GIL-indepedent reference when you want to store the reference elsewhere.
+// Take a GIL-independent reference when you want to store the reference elsewhere.
 #[pyfunction]
 fn print_refcnt(my_class: Py<MyClass>, py: Python<'_>) {
     println!("{}", my_class.get_refcnt(py));

guide/src/conversions/traits.md

@@ -613,7 +613,7 @@ Additionally `IntoPyObject` can be derived for a reference to a struct or enum u
 ##### `#[derive(IntoPyObject)]`/`#[derive(IntoPyObjectRef)]` Field Attributes
 - `pyo3(into_py_with = ...)`
     - apply a custom function to convert the field from Rust into Python.
-    - the argument must be the function indentifier
+    - the argument must be the function identifier
     - the function signature must be `fn(Cow<'_, T>, Python<'py>) -> PyResult<Bound<'py, PyAny>>` where `T` is the Rust type of the argument.
       - `#[derive(IntoPyObject)]` will invoke the function with `Cow::Owned`
       - `#[derive(IntoPyObjectRef)]` will invoke the function with `Cow::Borrowed`
@@ -650,7 +650,7 @@ struct MyPyObjectWrapper(PyObject);
 impl<'py> IntoPyObject<'py> for MyPyObjectWrapper {
     type Target = PyAny; // the Python type
     type Output = Bound<'py, Self::Target>; // in most cases this will be `Bound`
-    type Error = std::convert::Infallible; // the conversion error type, has to be convertable to `PyErr`
+    type Error = std::convert::Infallible; // the conversion error type, has to be convertible to `PyErr`
 
     fn into_pyobject(self, py: Python<'py>) -> Result<Self::Output, Self::Error> {
         Ok(self.0.into_bound(py))

guide/src/debugging.md

@@ -68,7 +68,7 @@ For more information about how to use both `lldb` and `gdb` you can read the [gd
 
 ### Debugger specific setup
 
-Depeding on your OS and your preferences you can use two different debuggers, `rust-gdb` or `rust-lldb`.
+Depending on your OS and your preferences you can use two different debuggers, `rust-gdb` or `rust-lldb`.
 
 {{#tabs }}
 {{#tab name="Using rust-gdb" }}

guide/src/features.md

@@ -77,7 +77,7 @@ This feature was introduced to ease migration. It was found that delayed referen
 
 ### `pyo3_disable_reference_pool`
 
-This is a performance-oriented conditional compilation flag, e.g. [set via `$RUSTFLAGS`][set-configuration-options], which disabled the global reference pool and the assocaited overhead for the crossing the Python-Rust boundary. However, if enabled, `Drop`ping an instance of `Py<T>` without the GIL being held will abort the process.
+This is a performance-oriented conditional compilation flag, e.g. [set via `$RUSTFLAGS`][set-configuration-options], which disabled the global reference pool and the associated overhead for the crossing the Python-Rust boundary. However, if enabled, `Drop`ping an instance of `Py<T>` without the GIL being held will abort the process.
 
 ### `macros`
 

guide/src/free-threading.md

@@ -148,7 +148,7 @@ GIL-enabled build instead ask the interpreter to attach the thread to the Python
 runtime, and there can be many threads simultaneously attached. See [PEP
 703](https://peps.python.org/pep-0703/#thread-states) for more background about
 how threads can be attached and detached from the interpreter runtime, in a
-manner analagous to releasing and acquiring the GIL in the GIL-enabled build.
+manner analogous to releasing and acquiring the GIL in the GIL-enabled build.
 
 In the GIL-enabled build, PyO3 uses the [`Python<'py>`] type and the `'py`
 lifetime to signify that the global interpreter lock is held. In the
@@ -289,7 +289,7 @@ GIL-enabled build.
 
 If, for example, the function executed by [`GILOnceCell`] releases the GIL or
 calls code that releases the GIL, then it is possible for multiple threads to
-race to initialize the cell. While the cell will only ever be intialized
+race to initialize the cell. While the cell will only ever be initialized
 once, it can be problematic in some contexts that [`GILOnceCell`] does not block
 like the standard library [`OnceLock`].
 

guide/src/migration.md

@@ -645,7 +645,7 @@ impl PyClassAsyncIter {
 <details>
 <summary><small>Click to expand</small></summary>
 
-Interactions with Python objects implemented in Rust no longer need to go though `PyCell<T>`. Instead iteractions with Python object now consistently go through `Bound<T>` or `Py<T>` independently of whether `T` is native Python object or a `#[pyclass]` implemented in Rust. Use `Bound::new` or `Py::new` respectively to create and `Bound::borrow(_mut)` / `Py::borrow(_mut)` to borrow the Rust object.
+Interactions with Python objects implemented in Rust no longer need to go though `PyCell<T>`. Instead interactions with Python object now consistently go through `Bound<T>` or `Py<T>` independently of whether `T` is native Python object or a `#[pyclass]` implemented in Rust. Use `Bound::new` or `Py::new` respectively to create and `Bound::borrow(_mut)` / `Py::borrow(_mut)` to borrow the Rust object.
 </details>
 
 ### Migrating from the GIL Refs API to `Bound<T>`
@@ -657,7 +657,7 @@ To minimise breakage of code using the GIL Refs API, the `Bound<T>` smart pointe
 To identify what to migrate, temporarily switch off the `gil-refs` feature to see deprecation warnings on [almost](#cases-where-pyo3-cannot-emit-gil-ref-deprecation-warnings) all uses of APIs accepting and producing GIL Refs . Over one or more PRs it should be possible to follow the deprecation hints to update code. Depending on your development environment, switching off the `gil-refs` feature may introduce [some very targeted breakages](#deactivating-the-gil-refs-feature), so you may need to fixup those first.
 
 For example, the following APIs have gained updated variants:
-- `PyList::new`, `PyTyple::new` and similar constructors have replacements `PyList::new_bound`, `PyTuple::new_bound` etc.
+- `PyList::new`, `PyTuple::new` and similar constructors have replacements `PyList::new_bound`, `PyTuple::new_bound` etc.
 - `FromPyObject::extract` has a new `FromPyObject::extract_bound` (see the section below)
 - The `PyTypeInfo` trait has had new `_bound` methods added to accept / return `Bound<T>`.
 
@@ -1082,7 +1082,7 @@ impl Object {
     }
 }
 
-// It either forces us to release the GIL before aquiring it again.
+// It either forces us to release the GIL before acquiring it again.
 let first = Python::with_gil(|py| Object::new(py));
 let second = Python::with_gil(|py| Object::new(py));
 drop(first);