diff --git a/crates/ty/docs/rules.md b/crates/ty/docs/rules.md index 3a52d48438..c4c39c0260 100644 --- a/crates/ty/docs/rules.md +++ b/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** diff --git a/crates/ty_python_semantic/resources/mdtest/annotations/callable.md b/crates/ty_python_semantic/resources/mdtest/annotations/callable.md index 688dcb321a..709e446493 100644 --- a/crates/ty_python_semantic/resources/mdtest/annotations/callable.md +++ b/crates/ty_python_semantic/resources/mdtest/annotations/callable.md @@ -4,7 +4,7 @@ References: - -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: ). 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`. diff --git a/crates/ty_python_semantic/resources/mdtest/annotations/union.md b/crates/ty_python_semantic/resources/mdtest/annotations/union.md index e4d47a3a94..776d077e27 100644 --- a/crates/ty_python_semantic/resources/mdtest/annotations/union.md +++ b/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 diff --git a/crates/ty_python_semantic/resources/mdtest/call/methods.md b/crates/ty_python_semantic/resources/mdtest/call/methods.md index 3c5ebbeb4d..1d6b020832 100644 --- a/crates/ty_python_semantic/resources/mdtest/call/methods.md +++ b/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: diff --git a/crates/ty_python_semantic/resources/mdtest/deprecated.md b/crates/ty_python_semantic/resources/mdtest/deprecated.md index a750952562..80d5108508 100644 --- a/crates/ty_python_semantic/resources/mdtest/deprecated.md +++ b/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 diff --git a/crates/ty_python_semantic/resources/mdtest/protocols.md b/crates/ty_python_semantic/resources/mdtest/protocols.md index 1d951ad3ed..c7d99dd917 100644 --- a/crates/ty_python_semantic/resources/mdtest/protocols.md +++ b/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 -# reference implementation for PEP-544, and its behaviour also matches the CPython -# runtime, so we choose to follow its behaviour here rather than that of the other +# but mypy does (and has an explicit test for this behavior). Mypy was the +# reference implementation for PEP-544, and its behavior also matches the CPython +# 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. -In the below example, the behaviour of an instance of `XAttr` is a superset of the behaviour -specified by the protocol `HasAsymmetricXProperty`. The protocol specifies that reading an `x` -attribute on the instance must resolve to an instance of `int` or a subclass thereof, and `XAttr` -satisfies this requirement. The protocol also specifies that you must be able to assign instances of -`MyInt` to the `x` attribute, and again this is satisfied by `XAttr`: on instances of `XAttr`, you -can assign *any* instance of `int` to the `x` attribute, and thus by extension you can assign any -instance of `IntSub` to the `x` attribute, since any instance of `IntSub` is an instance of `int`: +`X`'s behavior is a superset of the behavior specified by the interface declared by the protocol. In +the below example, the behavior of an instance of `XAttr` is a superset of the behavior specified by +the protocol `HasAsymmetricXProperty`. The protocol specifies that reading an `x` attribute on the +instance must resolve to an instance of `int` or a subclass thereof, and `XAttr` satisfies this +requirement. The protocol also specifies that you must be able to assign instances of `MyInt` to the +`x` attribute, and again this is satisfied by `XAttr`: on instances of `XAttr`, you can assign *any* +instance of `int` to the `x` attribute, and thus by extension you can assign any instance of +`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 diff --git a/crates/ty_python_semantic/resources/mdtest/scopes/moduletype_attrs.md b/crates/ty_python_semantic/resources/mdtest/scopes/moduletype_attrs.md index 140a4ac72b..7a438b9985 100644 --- a/crates/ty_python_semantic/resources/mdtest/scopes/moduletype_attrs.md +++ b/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`: diff --git a/crates/ty_python_semantic/resources/mdtest/suppressions/no_type_check.md b/crates/ty_python_semantic/resources/mdtest/suppressions/no_type_check.md index 37e3202061..a658031ed3 100644 --- a/crates/ty_python_semantic/resources/mdtest/suppressions/no_type_check.md +++ b/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. diff --git a/crates/ty_python_semantic/resources/mdtest/type_properties/is_singleton.md b/crates/ty_python_semantic/resources/mdtest/type_properties/is_singleton.md index a6b87194c9..25a55199ba 100644 --- a/crates/ty_python_semantic/resources/mdtest/type_properties/is_singleton.md +++ b/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] diff --git a/crates/ty_python_semantic/src/types/string_annotation.rs b/crates/ty_python_semantic/src/types/string_annotation.rs index 410996fd24..69f312f36a 100644 --- a/crates/ty_python_semantic/src/types/string_annotation.rs +++ b/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 diff --git a/ty.schema.json b/ty.schema.json index 25a660c49f..d91025b7f6 100644 --- a/ty.schema.json +++ b/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": [ {