[ty] Consistent use of American english (in rules) (#19488)

## Summary

Just noticed this as a minor inconsistency in our rules, and had Claude
do a few more automated replacements.

crates/ty/docs/rules.md

@@ -16,7 +16,7 @@ Checks for byte-strings in type annotation positions.
 
 **Why is this bad?**
 
-Static analysis tools like ty can't analyse type annotations that use byte-string notation.
+Static analysis tools like ty can't analyze type annotations that use byte-string notation.
 
 **Examples**
 
@@ -257,7 +257,7 @@ Checks for f-strings in type annotation positions.
 
 **Why is this bad?**
 
-Static analysis tools like ty can't analyse type annotations that use f-string notation.
+Static analysis tools like ty can't analyze type annotations that use f-string notation.
 
 **Examples**
 
@@ -286,7 +286,7 @@ Checks for implicit concatenated strings in type annotation positions.
 
 **Why is this bad?**
 
-Static analysis tools like ty can't analyse type annotations that use implicit concatenated strings.
+Static analysis tools like ty can't analyze type annotations that use implicit concatenated strings.
 
 **Examples**
 
@@ -1276,7 +1276,7 @@ Checks for raw-strings in type annotation positions.
 
 **Why is this bad?**
 
-Static analysis tools like ty can't analyse type annotations that use raw-string notation.
+Static analysis tools like ty can't analyze type annotations that use raw-string notation.
 
 **Examples**
 

crates/ty_python_semantic/resources/mdtest/annotations/callable.md

@@ -4,7 +4,7 @@ References:
 
 - <https://typing.python.org/en/latest/spec/callables.html#callable>
 
-Note that `typing.Callable` is deprecated at runtime, in favour of `collections.abc.Callable` (see:
+Note that `typing.Callable` is deprecated at runtime, in favor of `collections.abc.Callable` (see:
 <https://docs.python.org/3/library/typing.html#deprecated-aliases>). However, removal of
 `typing.Callable` is not currently planned, and the canonical location of the stub for the symbol in
 typeshed is still `typing.pyi`.

crates/ty_python_semantic/resources/mdtest/annotations/union.md

@@ -72,7 +72,7 @@ def f(x: Union) -> None:
 
 ## Implicit type aliases using new-style unions
 
-We don't recognise these as type aliases yet, but we also don't emit false-positive diagnostics if
+We don't recognize these as type aliases yet, but we also don't emit false-positive diagnostics if
 you use them in type expressions:
 
 ```toml

crates/ty_python_semantic/resources/mdtest/call/methods.md

@@ -204,7 +204,7 @@ reveal_type(IntOrStr.__or__)  # revealed: bound method typing.TypeAliasType.__or
 ## Method calls on types not disjoint from `None`
 
 Very few methods are defined on `object`, `None`, and other types not disjoint from `None`. However,
-descriptor-binding behaviour works on these types in exactly the same way as descriptor binding on
+descriptor-binding behavior works on these types in exactly the same way as descriptor binding on
 other types. This is despite the fact that `None` is used as a sentinel internally by the descriptor
 protocol to indicate that a method was accessed on the class itself rather than an instance of the
 class:

crates/ty_python_semantic/resources/mdtest/deprecated.md

@@ -54,7 +54,7 @@ class deprecated:
 ```
 
 Only the mandatory message string is of interest to static analysis, the other two affect only
-runtime behaviour.
+runtime behavior.
 
 ```py
 from typing_extensions import deprecated

crates/ty_python_semantic/resources/mdtest/protocols.md

@@ -11,7 +11,7 @@
 Most types in Python are *nominal* types: a fully static nominal type `X` is only a subtype of
 another fully static nominal type `Y` if the class `X` is a subclass of the class `Y`.
 `typing.Protocol` (or its backport, `typing_extensions.Protocol`) can be used to define *structural*
-types, on the other hand: a type which is defined by its properties and behaviour.
+types, on the other hand: a type which is defined by its properties and behavior.
 
 ## Defining a protocol
 
@@ -160,9 +160,9 @@ from typing import TypeVar, Generic
 T = TypeVar("T")
 
 # Note: pyright and pyrefly do not consider this to be a valid `Protocol` class,
-# but mypy does (and has an explicit test for this behaviour). Mypy was the
+# but mypy does (and has an explicit test for this behavior). Mypy was the
-# reference implementation for PEP-544, and its behaviour also matches the CPython
+# reference implementation for PEP-544, and its behavior also matches the CPython
-# runtime, so we choose to follow its behaviour here rather than that of the other
+# runtime, so we choose to follow its behavior here rather than that of the other
 # type checkers.
 class Fine(Protocol, object): ...
 
@@ -468,7 +468,7 @@ class AlsoNotAProtocol(NotAProtocol, object): ...
 get_protocol_members(AlsoNotAProtocol)  # error: [invalid-argument-type]
 ```
 
-The original class object must be passed to the function; a specialised version of a generic version
+The original class object must be passed to the function; a specialized version of a generic version
 does not suffice:
 
 ```py
@@ -886,7 +886,7 @@ class AlsoHasX(Protocol):
 static_assert(is_equivalent_to(HasX, AlsoHasX))
 ```
 
-And unions containing equivalent protocols are recognised as equivalent, even when the order is not
+And unions containing equivalent protocols are recognized as equivalent, even when the order is not
 identical:
 
 ```py
@@ -1318,14 +1318,14 @@ getter, can be satisfied by a mutable attribute of any type bounded by the upper
 getter-returned type and the lower bound of the setter-accepted type.
 
 This follows from the principle that a type `X` can only be a subtype of a given protocol if the
-`X`'s behaviour is a superset of the behaviour specified by the interface declared by the protocol.
+`X`'s behavior is a superset of the behavior specified by the interface declared by the protocol. In
-In the below example, the behaviour of an instance of `XAttr` is a superset of the behaviour
+the below example, the behavior of an instance of `XAttr` is a superset of the behavior specified by
-specified by the protocol `HasAsymmetricXProperty`. The protocol specifies that reading an `x`
+the protocol `HasAsymmetricXProperty`. The protocol specifies that reading an `x` attribute on the
-attribute on the instance must resolve to an instance of `int` or a subclass thereof, and `XAttr`
+instance must resolve to an instance of `int` or a subclass thereof, and `XAttr` satisfies this
-satisfies this requirement. The protocol also specifies that you must be able to assign instances of
+requirement. The protocol also specifies that you must be able to assign instances of `MyInt` to the
-`MyInt` to the `x` attribute, and again this is satisfied by `XAttr`: on instances of `XAttr`, you
+`x` attribute, and again this is satisfied by `XAttr`: on instances of `XAttr`, you can assign *any*
-can assign *any* instance of `int` to the `x` attribute, and thus by extension you can assign any
+instance of `int` to the `x` attribute, and thus by extension you can assign any instance of
-instance of `IntSub` to the `x` attribute, since any instance of `IntSub` is an instance of `int`:
+`IntSub` to the `x` attribute, since any instance of `IntSub` is an instance of `int`:
 
 ```py
 class HasAsymmetricXProperty(Protocol):
@@ -1495,7 +1495,7 @@ static_assert(is_equivalent_to(A | B | P1, P2 | B | A))
 
 By default, a protocol class cannot be used as the second argument to `isinstance()` or
 `issubclass()`, and a type checker must emit an error on such calls. However, we still narrow the
-type inside these branches (this matches the behaviour of other type checkers):
+type inside these branches (this matches the behavior of other type checkers):
 
 ```py
 from typing_extensions import Protocol, reveal_type
@@ -1674,7 +1674,7 @@ static_assert(is_assignable_to(TypeOf[satisfies_foo], Foo))
 It *might* be possible to have a singleton protocol-instance type...?
 
 For example, `WeirdAndWacky` in the following snippet only has a single possible inhabitant: `None`!
-It is thus a singleton type. However, going out of our way to recognise it as such is probably not
+It is thus a singleton type. However, going out of our way to recognize it as such is probably not
 worth it. Such cases should anyway be exceedingly rare and/or contrived.
 
 ```py

crates/ty_python_semantic/resources/mdtest/scopes/moduletype_attrs.md

@@ -119,7 +119,7 @@ reveal_type(typing.__getattr__)  # revealed: Unknown
 ## `types.ModuleType.__dict__` takes precedence over global variable `__dict__`
 
 It's impossible to override the `__dict__` attribute of `types.ModuleType` instances from inside the
-module; we should prioritise the attribute in the `types.ModuleType` stub over a variable named
+module; we should prioritize the attribute in the `types.ModuleType` stub over a variable named
 `__dict__` in the module's global namespace:
 
 `foo.py`:

crates/ty_python_semantic/resources/mdtest/suppressions/no_type_check.md

@@ -93,7 +93,7 @@ def test() -> Undefined:
 
 ## `no_type_check` on classes isn't supported
 
-ty does not support decorating classes with `no_type_check`. The behaviour of `no_type_check` when
+ty does not support decorating classes with `no_type_check`. The behavior of `no_type_check` when
 applied to classes is
 [not specified currently](https://typing.python.org/en/latest/spec/directives.html#no-type-check),
 and is not supported by Pyright or mypy.

crates/ty_python_semantic/resources/mdtest/type_properties/is_singleton.md

@@ -75,7 +75,7 @@ static_assert(is_singleton(_NoDefaultType))
 ### All Python versions
 
 The type of the builtin symbol `Ellipsis` is the same as the type of an ellipsis literal (`...`).
-The type is not actually exposed from the standard library on Python \<3.10, but we still recognise
+The type is not actually exposed from the standard library on Python \<3.10, but we still recognize
 the type as a singleton on any Python version.
 
 ```toml
@@ -93,7 +93,7 @@ static_assert(is_singleton((...).__class__))
 ### Python 3.10+
 
 On Python 3.10+, the standard library exposes the type of `...` as `types.EllipsisType`, and we also
-recognise this as a singleton type when it is referenced directly:
+recognize this as a singleton type when it is referenced directly:
 
 ```toml
 [environment]

crates/ty_python_semantic/src/types/string_annotation.rs

@@ -13,7 +13,7 @@ declare_lint! {
     /// Checks for f-strings in type annotation positions.
     ///
     /// ## Why is this bad?
-    /// Static analysis tools like ty can't analyse type annotations that use f-string notation.
+    /// Static analysis tools like ty can't analyze type annotations that use f-string notation.
     ///
     /// ## Examples
     /// ```python
@@ -38,7 +38,7 @@ declare_lint! {
         /// Checks for byte-strings in type annotation positions.
         ///
         /// ## Why is this bad?
-        /// Static analysis tools like ty can't analyse type annotations that use byte-string notation.
+        /// Static analysis tools like ty can't analyze type annotations that use byte-string notation.
         ///
         /// ## Examples
         /// ```python
@@ -63,7 +63,7 @@ declare_lint! {
         /// Checks for raw-strings in type annotation positions.
         ///
         /// ## Why is this bad?
-        /// Static analysis tools like ty can't analyse type annotations that use raw-string notation.
+        /// Static analysis tools like ty can't analyze type annotations that use raw-string notation.
         ///
         /// ## Examples
         /// ```python
@@ -88,7 +88,7 @@ declare_lint! {
         /// Checks for implicit concatenated strings in type annotation positions.
         ///
         /// ## Why is this bad?
-        /// Static analysis tools like ty can't analyse type annotations that use implicit concatenated strings.
+        /// Static analysis tools like ty can't analyze type annotations that use implicit concatenated strings.
         ///
         /// ## Examples
         /// ```python

ty.schema.json

@@ -273,7 +273,7 @@
       "properties": {
         "byte-string-type-annotation": {
           "title": "detects byte strings in type annotation positions",
-          "description": "## What it does\nChecks for byte-strings in type annotation positions.\n\n## Why is this bad?\nStatic analysis tools like ty can't analyse type annotations that use byte-string notation.\n\n## Examples\n```python\ndef test(): -> b\"int\":\n    ...\n```\n\nUse instead:\n```python\ndef test(): -> \"int\":\n    ...\n```",
+          "description": "## What it does\nChecks for byte-strings in type annotation positions.\n\n## Why is this bad?\nStatic analysis tools like ty can't analyze type annotations that use byte-string notation.\n\n## Examples\n```python\ndef test(): -> b\"int\":\n    ...\n```\n\nUse instead:\n```python\ndef test(): -> \"int\":\n    ...\n```",
           "default": "error",
           "oneOf": [
             {
@@ -383,7 +383,7 @@
         },
         "fstring-type-annotation": {
           "title": "detects F-strings in type annotation positions",
-          "description": "## What it does\nChecks for f-strings in type annotation positions.\n\n## Why is this bad?\nStatic analysis tools like ty can't analyse type annotations that use f-string notation.\n\n## Examples\n```python\ndef test(): -> f\"int\":\n    ...\n```\n\nUse instead:\n```python\ndef test(): -> \"int\":\n    ...\n```",
+          "description": "## What it does\nChecks for f-strings in type annotation positions.\n\n## Why is this bad?\nStatic analysis tools like ty can't analyze type annotations that use f-string notation.\n\n## Examples\n```python\ndef test(): -> f\"int\":\n    ...\n```\n\nUse instead:\n```python\ndef test(): -> \"int\":\n    ...\n```",
           "default": "error",
           "oneOf": [
             {
@@ -393,7 +393,7 @@
         },
         "implicit-concatenated-string-type-annotation": {
           "title": "detects implicit concatenated strings in type annotations",
-          "description": "## What it does\nChecks for implicit concatenated strings in type annotation positions.\n\n## Why is this bad?\nStatic analysis tools like ty can't analyse type annotations that use implicit concatenated strings.\n\n## Examples\n```python\ndef test(): -> \"Literal[\" \"5\" \"]\":\n    ...\n```\n\nUse instead:\n```python\ndef test(): -> \"Literal[5]\":\n    ...\n```",
+          "description": "## What it does\nChecks for implicit concatenated strings in type annotation positions.\n\n## Why is this bad?\nStatic analysis tools like ty can't analyze type annotations that use implicit concatenated strings.\n\n## Examples\n```python\ndef test(): -> \"Literal[\" \"5\" \"]\":\n    ...\n```\n\nUse instead:\n```python\ndef test(): -> \"Literal[5]\":\n    ...\n```",
           "default": "error",
           "oneOf": [
             {
@@ -763,7 +763,7 @@
         },
         "raw-string-type-annotation": {
           "title": "detects raw strings in type annotation positions",
-          "description": "## What it does\nChecks for raw-strings in type annotation positions.\n\n## Why is this bad?\nStatic analysis tools like ty can't analyse type annotations that use raw-string notation.\n\n## Examples\n```python\ndef test(): -> r\"int\":\n    ...\n```\n\nUse instead:\n```python\ndef test(): -> \"int\":\n    ...\n```",
+          "description": "## What it does\nChecks for raw-strings in type annotation positions.\n\n## Why is this bad?\nStatic analysis tools like ty can't analyze type annotations that use raw-string notation.\n\n## Examples\n```python\ndef test(): -> r\"int\":\n    ...\n```\n\nUse instead:\n```python\ndef test(): -> \"int\":\n    ...\n```",
           "default": "error",
           "oneOf": [
             {