Reverted words misunderstood as typo

Code-of-Conduct.md

@@ -11,7 +11,7 @@ appearance, race, religion, or sexual identity and orientation.
 
 ## Our Standards
 
-Examples of behavior that contributes to creating a positive environment
+Examples of behaviour that contributes to creating a positive environment
 include:
 
 * Using welcoming and inclusive language
@@ -20,7 +20,7 @@ include:
 * Focusing on what is best for the community
 * Showing empathy towards other community members
 
-Examples of unacceptable behavior by participants include:
+Examples of unacceptable behaviour by participants include:
 
 * The use of sexualized language or imagery and unwelcome sexual attention or
   advances
@@ -34,13 +34,13 @@ Examples of unacceptable behavior by participants include:
 ## Our Responsibilities
 
 Project maintainers are responsible for clarifying the standards of acceptable
-behavior and are expected to take appropriate and fair corrective action in
-response to any instances of unacceptable behavior.
+behaviour and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behaviour.
 
 Project maintainers have the right and responsibility to remove, edit, or
 reject comments, commits, code, wiki edits, issues, and other contributions
 that are not aligned to this Code of Conduct, or to ban temporarily or
-permanently any contributor for other behaviors that they deem inappropriate,
+permanently any contributor for other behaviours that they deem inappropriate,
 threatening, offensive, or harmful.
 
 ## Scope
@@ -54,7 +54,7 @@ further defined and clarified by project maintainers.
 
 ## Enforcement
 
-Instances of abusive, harassing, or otherwise unacceptable behavior may be
+Instances of abusive, harassing, or otherwise unacceptable behaviour may be
 reported by contacting the project team. All
 complaints will be reviewed and investigated and will result in a response that
 is deemed necessary and appropriate to the circumstances. The project team is

README.md

@@ -396,7 +396,7 @@ RuntimeError: no running event loop
 ```
 
 What's happening here is that we are calling `rust_sleep` _before_ the future is
-actually running on the event loop created by `asyncio.run`. This is counter-intuitive, but expected behavior, and unfortunately there doesn't seem to be a good way of solving this problem within PyO3 Asyncio itself.
+actually running on the event loop created by `asyncio.run`. This is counter-intuitive, but expected behaviour, and unfortunately there doesn't seem to be a good way of solving this problem within PyO3 Asyncio itself.
 
 However, we can make this example work with a simple workaround:
 
@@ -541,7 +541,7 @@ fn main() -> PyResult<()> {
 
 So what's changed from `v0.13` to `v0.14`?
 
-Well, a lot actually. There were some pretty major flaws in the initialization behavior of `v0.13`. While it would have been nicer to address these issues without changing the public API, I decided it'd be better to break some of the old API rather than completely change the underlying behavior of the existing functions. I realize this is going to be a bit of a headache, so hopefully this section will help you through it.
+Well, a lot actually. There were some pretty major flaws in the initialization behaviour of `v0.13`. While it would have been nicer to address these issues without changing the public API, I decided it'd be better to break some of the old API rather than completely change the underlying behaviour of the existing functions. I realize this is going to be a bit of a headache, so hopefully this section will help you through it.
 
 To make things a bit easier, I decided to keep most of the old API alongside the new one (with some deprecation warnings to encourage users to move away from it). It should be possible to use the `v0.13` API alongside the newer `v0.14` API, which should allow you to upgrade your application piecemeal rather than all at once.
 
@@ -569,7 +569,7 @@ To make things a bit easier, I decided to keep most of the old API alongside the
 ### Upgrading Your Code to 0.14
 
 1. Fix PyO3 0.14 initialization.
-   - PyO3 0.14 feature gated its automatic initialization behavior behind "auto-initialize". You can either enable the "auto-initialize" behavior in your project or add a call to `pyo3::prepare_freethreaded_python()` to the start of your program.
+   - PyO3 0.14 feature gated its automatic initialization behaviour behind "auto-initialize". You can either enable the "auto-initialize" behaviour in your project or add a call to `pyo3::prepare_freethreaded_python()` to the start of your program.
    - If you're using the `#[pyo3_asyncio::<runtime>::main]` proc macro attributes, then you can skip this step. `#[pyo3_asyncio::<runtime>::main]` will call `pyo3::prepare_freethreaded_python()` at the start regardless of your project's "auto-initialize" feature.
 2. Fix the tokio initialization.
 
@@ -646,7 +646,7 @@ To make things a bit easier, I decided to keep most of the old API alongside the
 There have been a few changes to the API in order to support proper cancellation from Python and the `contextvars` module.
 
 - Any instance of `cancellable_future_into_py` and `local_cancellable_future_into_py` conversions can be replaced with their`future_into_py` and `local_future_into_py` counterparts.
-  > Cancellation support became the default behavior in 0.15.
+  > Cancellation support became the default behaviour in 0.15.
 - Instances of `*_with_loop` conversions should be replaced with the newer `*_with_locals` conversions.
 
   ```rust no_run

src/async_std.rs

@@ -230,10 +230,10 @@ where
 /// Convert a Rust Future into a Python awaitable
 ///
 /// If the `asyncio.Future` returned by this conversion is cancelled via `asyncio.Future.cancel`,
-/// the Rust future will be cancelled as well (new behavior in `v0.15`).
+/// the Rust future will be cancelled as well (new behaviour in `v0.15`).
 ///
 /// Python `contextvars` are preserved when calling async Python functions within the Rust future
-/// via [`into_future`] (new behavior in `v0.15`).
+/// via [`into_future`] (new behaviour in `v0.15`).
 ///
 /// > Although `contextvars` are preserved for async Python functions, synchronous functions will
 /// unfortunately fail to resolve them when called within the Rust future. This is because the
@@ -285,10 +285,10 @@ where
 /// Convert a Rust Future into a Python awaitable
 ///
 /// If the `asyncio.Future` returned by this conversion is cancelled via `asyncio.Future.cancel`,
-/// the Rust future will be cancelled as well (new behavior in `v0.15`).
+/// the Rust future will be cancelled as well (new behaviour in `v0.15`).
 ///
 /// Python `contextvars` are preserved when calling async Python functions within the Rust future
-/// via [`into_future`] (new behavior in `v0.15`).
+/// via [`into_future`] (new behaviour in `v0.15`).
 ///
 /// > Although `contextvars` are preserved for async Python functions, synchronous functions will
 /// unfortunately fail to resolve them when called within the Rust future. This is because the
@@ -331,10 +331,10 @@ where
 /// Convert a `!Send` Rust Future into a Python awaitable
 ///
 /// If the `asyncio.Future` returned by this conversion is cancelled via `asyncio.Future.cancel`,
-/// the Rust future will be cancelled as well (new behavior in `v0.15`).
+/// the Rust future will be cancelled as well (new behaviour in `v0.15`).
 ///
 /// Python `contextvars` are preserved when calling async Python functions within the Rust future
-/// via [`into_future`] (new behavior in `v0.15`).
+/// via [`into_future`] (new behaviour in `v0.15`).
 ///
 /// > Although `contextvars` are preserved for async Python functions, synchronous functions will
 /// unfortunately fail to resolve them when called within the Rust future. This is because the
@@ -406,10 +406,10 @@ where
 /// Convert a `!Send` Rust Future into a Python awaitable
 ///
 /// If the `asyncio.Future` returned by this conversion is cancelled via `asyncio.Future.cancel`,
-/// the Rust future will be cancelled as well (new behavior in `v0.15`).
+/// the Rust future will be cancelled as well (new behaviour in `v0.15`).
 ///
 /// Python `contextvars` are preserved when calling async Python functions within the Rust future
-/// via [`into_future`] (new behavior in `v0.15`).
+/// via [`into_future`] (new behaviour in `v0.15`).
 ///
 /// > Although `contextvars` are preserved for async Python functions, synchronous functions will
 /// unfortunately fail to resolve them when called within the Rust future. This is because the

src/generic.rs

@@ -472,10 +472,10 @@ where
 /// Convert a Rust Future into a Python awaitable with a generic runtime
 ///
 /// If the `asyncio.Future` returned by this conversion is cancelled via `asyncio.Future.cancel`,
-/// the Rust future will be cancelled as well (new behavior in `v0.15`).
+/// the Rust future will be cancelled as well (new behaviour in `v0.15`).
 ///
 /// Python `contextvars` are preserved when calling async Python functions within the Rust future
-/// via [`into_future`] (new behavior in `v0.15`).
+/// via [`into_future`] (new behaviour in `v0.15`).
 ///
 /// > Although `contextvars` are preserved for async Python functions, synchronous functions will
 /// unfortunately fail to resolve them when called within the Rust future. This is because the
@@ -744,10 +744,10 @@ impl PyDoneCallback {
 /// Convert a Rust Future into a Python awaitable with a generic runtime
 ///
 /// If the `asyncio.Future` returned by this conversion is cancelled via `asyncio.Future.cancel`,
-/// the Rust future will be cancelled as well (new behavior in `v0.15`).
+/// the Rust future will be cancelled as well (new behaviour in `v0.15`).
 ///
 /// Python `contextvars` are preserved when calling async Python functions within the Rust future
-/// via [`into_future`] (new behavior in `v0.15`).
+/// via [`into_future`] (new behaviour in `v0.15`).
 ///
 /// > Although `contextvars` are preserved for async Python functions, synchronous functions will
 /// unfortunately fail to resolve them when called within the Rust future. This is because the
@@ -852,10 +852,10 @@ where
 /// specification of task locals.
 ///
 /// If the `asyncio.Future` returned by this conversion is cancelled via `asyncio.Future.cancel`,
-/// the Rust future will be cancelled as well (new behavior in `v0.15`).
+/// the Rust future will be cancelled as well (new behaviour in `v0.15`).
 ///
 /// Python `contextvars` are preserved when calling async Python functions within the Rust future
-/// via [`into_future`] (new behavior in `v0.15`).
+/// via [`into_future`] (new behaviour in `v0.15`).
 ///
 /// > Although `contextvars` are preserved for async Python functions, synchronous functions will
 /// unfortunately fail to resolve them when called within the Rust future. This is because the
@@ -1057,10 +1057,10 @@ where
 /// Convert a `!Send` Rust Future into a Python awaitable with a generic runtime
 ///
 /// If the `asyncio.Future` returned by this conversion is cancelled via `asyncio.Future.cancel`,
-/// the Rust future will be cancelled as well (new behavior in `v0.15`).
+/// the Rust future will be cancelled as well (new behaviour in `v0.15`).
 ///
 /// Python `contextvars` are preserved when calling async Python functions within the Rust future
-/// via [`into_future`] (new behavior in `v0.15`).
+/// via [`into_future`] (new behaviour in `v0.15`).
 ///
 /// > Although `contextvars` are preserved for async Python functions, synchronous functions will
 /// unfortunately fail to resolve them when called within the Rust future. This is because the

src/tokio.rs

@@ -272,10 +272,10 @@ where
 /// Convert a Rust Future into a Python awaitable
 ///
 /// If the `asyncio.Future` returned by this conversion is cancelled via `asyncio.Future.cancel`,
-/// the Rust future will be cancelled as well (new behavior in `v0.15`).
+/// the Rust future will be cancelled as well (new behaviour in `v0.15`).
 ///
 /// Python `contextvars` are preserved when calling async Python functions within the Rust future
-/// via [`into_future`] (new behavior in `v0.15`).
+/// via [`into_future`] (new behaviour in `v0.15`).
 ///
 /// > Although `contextvars` are preserved for async Python functions, synchronous functions will
 /// unfortunately fail to resolve them when called within the Rust future. This is because the
@@ -327,10 +327,10 @@ where
 /// Convert a Rust Future into a Python awaitable
 ///
 /// If the `asyncio.Future` returned by this conversion is cancelled via `asyncio.Future.cancel`,
-/// the Rust future will be cancelled as well (new behavior in `v0.15`).
+/// the Rust future will be cancelled as well (new behaviour in `v0.15`).
 ///
 /// Python `contextvars` are preserved when calling async Python functions within the Rust future
-/// via [`into_future`] (new behavior in `v0.15`).
+/// via [`into_future`] (new behaviour in `v0.15`).
 ///
 /// > Although `contextvars` are preserved for async Python functions, synchronous functions will
 /// unfortunately fail to resolve them when called within the Rust future. This is because the
@@ -373,10 +373,10 @@ where
 /// Convert a `!Send` Rust Future into a Python awaitable
 ///
 /// If the `asyncio.Future` returned by this conversion is cancelled via `asyncio.Future.cancel`,
-/// the Rust future will be cancelled as well (new behavior in `v0.15`).
+/// the Rust future will be cancelled as well (new behaviour in `v0.15`).
 ///
 /// Python `contextvars` are preserved when calling async Python functions within the Rust future
-/// via [`into_future`] (new behavior in `v0.15`).
+/// via [`into_future`] (new behaviour in `v0.15`).
 ///
 /// > Although `contextvars` are preserved for async Python functions, synchronous functions will
 /// unfortunately fail to resolve them when called within the Rust future. This is because the
@@ -464,10 +464,10 @@ where
 /// Convert a `!Send` Rust Future into a Python awaitable
 ///
 /// If the `asyncio.Future` returned by this conversion is cancelled via `asyncio.Future.cancel`,
-/// the Rust future will be cancelled as well (new behavior in `v0.15`).
+/// the Rust future will be cancelled as well (new behaviour in `v0.15`).
 ///
 /// Python `contextvars` are preserved when calling async Python functions within the Rust future
-/// via [`into_future`] (new behavior in `v0.15`).
+/// via [`into_future`] (new behaviour in `v0.15`).
 ///
 /// > Although `contextvars` are preserved for async Python functions, synchronous functions will
 /// unfortunately fail to resolve them when called within the Rust future. This is because the