Thanks for writing this proposal, Jelle. I like the proposal for `assert_type`. It doesn't allow for checking the textual representation of a type, but that's not important for most target users of this functionality. I personally have a need for that in the pyright unit tests, but I can use a pyright-specific extension to handle that use case. Presumably other type checkers could do the same if they want to validate the textual representations of types they produce. I'm pretty negative on the proposal for `assert_error`. This seems like an abuse of a context manager. As you point out, there is no precedent for type checkers using context managers in this manner. There are many potential type errors and warnings that could be reported, and the granularity and nature of these errors is not well specified in any PEP, so standardizing a mechanism that says "there must be a type error reported here" is fraught with challenges. My recommendation is to remove `assert_error` from the proposal. I don't see a way to overcome these challenges, and I don't think the use case is sufficiently compelling to introduce a mechanism that has no precedent. -Eric -- Eric Traut Contributor to Pyright & Pylance Microsoft

El sáb, 22 ene 2022 a las 16:51, Martin DeMello () escribió:

Is the ultimate goal to let inline tests be written as part of a type stub? Or are you just looking for a lighter weight way to write a separate test suite?

I don't think these functions should be used in stubs directly. I anticipate that typeshed would have a separate tests directory full of `assert_type()` and `assert_error()`, with CI that runs each supported type checker on the tests.

martin

On Sat, Jan 22, 2022 at 4:07 PM Jelle Zijlstra wrote:

...

Don't worry, this is the last one for today, but probably the trickiest.

These two functions are intended to help users who want to check how their API behaves with a type checker: they want to assert that some type is inferred correctly, or that some code that they want the type checker to catch is rejected.

# Specification

The signature of typing.assert_type() is:

def assert_type(obj: T, typ: TypeForm[T], /) -> T: ...

(Using TypeForm from David Foster's pending proposal.)

At runtime, this simply returns the first argument unchanged. As with my proposed behavior for reveal_type(), this allows using the function within an expression.

A static type checker will emit an error if it encounters a call to assert_type() and the inferred type for the obj argument is not exactly equal to the provided type. The type passed in as the `typ` argument is interpreted the same way the type checker would interpret a type annotation, just as with the first argument to the existing `typing.cast()` function.

For example:

def f(x: int): assert_type(x, int) # ok assert_type(x, str) # error: type of x is int, not str assert_type(x, Any) # error: type of x is int, not Any

The signature of typing.assert_error() is:

def assert_error() -> ContextManager[None]: ...

At runtime, this returns a context manager that does nothing.

At type checking time, the context asserts that an error is found within the block. A static type checker will handle a `with assert_error():` block as follows: - Type check the block as normal, but don't emit any errors to the user - If there were no errors, emit an error - If there were errors, continue as normal

For example:

with assert_error(): # ok 1 + "x" with assert_error(): # error 1 + 1

# Motivation

There has been a longstanding need for a way to check that typed code is understood correctly by the type checker: - https://github.com/python/typeshed/issues/1339 - typeshed issue looking for a way to test typeshed stubs - https://github.com/python/typing/discussions/1030 - recent discussion looking for the same thing in user code - https://pypi.org/project/pytest-mypy-plugins/ provides a mypy-specific way to test inferred types - https://google.github.io/pytype/faq.html#can-i-find-out-what-pytype-thinks-t... - pytype added an assert_type() function as proposed here based on user feedback

Adding these two functions to the standard library with defined semantics will create a portable, well-documented way to test type checker behavior. This will be useful for typeshed and for any library author who needs to support multiple type checkers.

# Use case

As a motivating example, I'd like to go over a recent change I made to typeshed: https://github.com/python/typeshed/pull/6941. I wanted to make it so that you cannot call `dict.setdefault()` with one argument if the dict's value type does not include `None`, so I wrote some tricky overloads.

With `assert_type()` and `assert_error()`, I could have written tests like these to make sure my stubs work with all type checkers:

int_int: dict[int, int] = {} int_any: dict[int, Any] = {} int_optional: dict[int, int | None] = {} with assert_error(): int_int.setdefault(1) # should error because this may set the value to None

assert_type(int_int.setdefault(1, 1), int) assert_type(int_any.setdefault(1), Any) assert_type(int_optional.setdefault(1), int | None)

What I did instead was run some samples manually with mypy, but that of course doesn't guarantee that the sample continues to work.

This example comes from typeshed, but the utility isn't limited to typeshed; it can help any user who wants to make sure the types they wrote behave as they expect.

# Open issues

The assert_error() context manager is unlike other existing special forms in the typing module, since no other context manager currently has special meaning to the type checker. I'd be happy to hear any alternative ideas for covering this use case.

Here are two alternative approaches I considered: - A magical comment, like TypeScript's "// $ExpectError". But a magical comment is not as explicit, is harder to understand for users, and may cause problems with autoformatters. - A function call: perhaps `typing.assert_type(expr, typing.Error)` would assert that evaluating `expr` produces an error. But this wouldn't allow asserting that an error occurs in a statement as opposed to an expression.

In https://github.com/python/typing/discussions/1030, we explored several variants for the behavior of assert_type(), such as allowing an explicit way to provide the type as a string. I think the behavior specified here is the most intuitive and consistent with the behavior of other typing constructs, but I'm happy to discuss this further. _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: mdemello@google.com

On Sat, Jan 22, 2022 at 4:54 PM Jelle Zijlstra wrote:

El sáb, 22 ene 2022 a las 16:51, Martin DeMello () escribió:

...

Is the ultimate goal to let inline tests be written as part of a type stub? Or are you just looking for a lighter weight way to write a separate test suite?

I don't think these functions should be used in stubs directly. I anticipate that typeshed would have a separate tests directory full of `assert_type()` and `assert_error()`, with CI that runs each supported type checker on the tests.

...

...

The scheme we use for pytype's unit tests is worth considering, then - types asserted via assert_type, but errors asserted with comments. So e.g. x = 1 assert_type(x, int) x.strip() # attribute-error[e] The [e] after the error code is optional, but if supplied the full text of the error will be captured as errors["e"], so that assertions can be run on it. We currently express the test snippets themselves as strings in the code, but if people like the general idea I would be happy to work up a proposal for some sort of structured format to have several tests in a single file, and for some form of error assertion that is not tied to pytype's specific error codes. martin

The only real use-case for `assert_error` for library authors I see is a custom mypy plugin. It can (and probably will) contain custom errors, which you need to check somehow. Example: https://github.com/dry-python/classes/blob/986c83169fcfd1eb312d1cb4599888738... But, I think at this point, people would need full-featured testing tools. вс, 23 янв. 2022 г. в 05:28, Eric Traut :

I'm looking at this from the perspective of Python library authors, not through the eyes of a type checker author. I realize that type checker authors have some special needs for our own tests, but we have the ability to add mechanisms specific to our type checkers to address those needs.

For library authors, I think they're mostly interested in validating that types evaluate correctly, hence the desire for something like `assert_type`. I've had several requests for exposing something like this in pyright. I presume that the maintainers of pytype also had similar requests, which led them to add their implementation of `assert_type`.

I don't recall ever receiving a request for a block-scoped mechanism like you've proposed for `assert_error`. I also don't recall seeing any requests for such a mechanism in the mypy issue tracker.

The functionality in the proposed `assert_error` seems redundant with existing comment-based mechanisms. In all Python type checkers you can specify a `# type: ignore` comment on a line to suppress a type error. In both mypy and pyright (I'm not sure about the other type checkers), you can also specify that unnecessary `# type: ignore` comments should generate an error. That combination of features seems like it would already cover the use case that you're trying to address with `assert_error`.

-Eric _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: n.a.sobolev@gmail.com

Interesting proposal - definitely seems there’s a desire by authors of (complex) libraries to not merely have type checkers verify their library code passes, but also to test that their annotations are understood by checkers in the desired way. I thought it might be useful to point out there was just a discussion about this by the pandas project - https://github.com/pandas-dev/pandas/issues/45252. They discussed some similar strategies as in this thread. Support for a standardized method might make setting up their typing tests easier. There’s also the method used by numpy: https://github.com/numpy/numpy/tree/main/numpy/typing/tests/data. They have one set of code samples that is verified to pass, one for files that fail with the expected error messages included as inline comments, and one for using reveal_type with inline comments again. The only substantive feedback I have is 1) I think there are some details of how type info is output by checkers that are not well documented or standardized (https://github.com/python/mypy/issues/11519), which would make this harder to use in a typechecker-agnostic way: e.g. mypy sometimes appends asterisks, numeric IDs, or ? to types. Also 2), it might be nice to be able to use type aliases in writing out the expected types/errors, in case they are very long.

Thanks everyone for the feedback in this thread! https://github.com/python/cpython/pull/30843 is the draft CPython implementation. As with the others, any suggestions are welcome. Based on the messages here, I have dropped assert_error() for now. El sáb, 22 ene 2022 a las 16:06, Jelle Zijlstra () escribió:

Don't worry, this is the last one for today, but probably the trickiest.

These two functions are intended to help users who want to check how their API behaves with a type checker: they want to assert that some type is inferred correctly, or that some code that they want the type checker to catch is rejected.

# Specification

The signature of typing.assert_type() is:

def assert_type(obj: T, typ: TypeForm[T], /) -> T: ...

(Using TypeForm from David Foster's pending proposal.)

At runtime, this simply returns the first argument unchanged. As with my proposed behavior for reveal_type(), this allows using the function within an expression.

A static type checker will emit an error if it encounters a call to assert_type() and the inferred type for the obj argument is not exactly equal to the provided type. The type passed in as the `typ` argument is interpreted the same way the type checker would interpret a type annotation, just as with the first argument to the existing `typing.cast()` function.

For example:

def f(x: int): assert_type(x, int) # ok assert_type(x, str) # error: type of x is int, not str assert_type(x, Any) # error: type of x is int, not Any

The signature of typing.assert_error() is:

def assert_error() -> ContextManager[None]: ...

At runtime, this returns a context manager that does nothing.

At type checking time, the context asserts that an error is found within the block. A static type checker will handle a `with assert_error():` block as follows: - Type check the block as normal, but don't emit any errors to the user - If there were no errors, emit an error - If there were errors, continue as normal

For example:

with assert_error(): # ok 1 + "x" with assert_error(): # error 1 + 1

# Motivation

There has been a longstanding need for a way to check that typed code is understood correctly by the type checker: - https://github.com/python/typeshed/issues/1339 - typeshed issue looking for a way to test typeshed stubs - https://github.com/python/typing/discussions/1030 - recent discussion looking for the same thing in user code - https://pypi.org/project/pytest-mypy-plugins/ provides a mypy-specific way to test inferred types - https://google.github.io/pytype/faq.html#can-i-find-out-what-pytype-thinks-t... - pytype added an assert_type() function as proposed here based on user feedback

Adding these two functions to the standard library with defined semantics will create a portable, well-documented way to test type checker behavior. This will be useful for typeshed and for any library author who needs to support multiple type checkers.

# Use case

As a motivating example, I'd like to go over a recent change I made to typeshed: https://github.com/python/typeshed/pull/6941. I wanted to make it so that you cannot call `dict.setdefault()` with one argument if the dict's value type does not include `None`, so I wrote some tricky overloads.

With `assert_type()` and `assert_error()`, I could have written tests like these to make sure my stubs work with all type checkers:

int_int: dict[int, int] = {} int_any: dict[int, Any] = {} int_optional: dict[int, int | None] = {} with assert_error(): int_int.setdefault(1) # should error because this may set the value to None

assert_type(int_int.setdefault(1, 1), int) assert_type(int_any.setdefault(1), Any) assert_type(int_optional.setdefault(1), int | None)

What I did instead was run some samples manually with mypy, but that of course doesn't guarantee that the sample continues to work.

This example comes from typeshed, but the utility isn't limited to typeshed; it can help any user who wants to make sure the types they wrote behave as they expect.

# Open issues

The assert_error() context manager is unlike other existing special forms in the typing module, since no other context manager currently has special meaning to the type checker. I'd be happy to hear any alternative ideas for covering this use case.

Here are two alternative approaches I considered: - A magical comment, like TypeScript's "// $ExpectError". But a magical comment is not as explicit, is harder to understand for users, and may cause problems with autoformatters. - A function call: perhaps `typing.assert_type(expr, typing.Error)` would assert that evaluating `expr` produces an error. But this wouldn't allow asserting that an error occurs in a statement as opposed to an expression.

In https://github.com/python/typing/discussions/1030, we explored several variants for the behavior of assert_type(), such as allowing an explicit way to provide the type as a string. I think the behavior specified here is the most intuitive and consistent with the behavior of other typing constructs, but I'm happy to discuss this further.

I'd be curious to hear thoughts from others, but I'd prefer to stick with the assert_type() name. Several of us came up with the same name independently, so it's the most obvious name. While there is some potential for confusion, the function lives in the `typing` namespace, which should make it obvious that it's meant for static typing, not runtime checks. El jue, 3 feb 2022 a las 7:51, David Foster () escribió:

On 1/23/22 4:39 PM, Jelle Zijlstra wrote:

...

https://github.com/python/cpython/pull/30843 is the draft CPython implementation. As with the others, any suggestions are welcome. [...]

It occurs to me that users of "assert_type()" - with that function name - may be surprised that it doesn't actually perform an assertion at runtime, considering that a regular "assert" statement *does* make a runtime check. Consider code like:

def parse_int(value) -> int: assert_type(value, str) # easily read incorrectly as: assert isinstance(value, str) return int(value)

I wonder if we might consider a word other than "assert", or maybe add the word "static" somewhere. Ideas:

* prove_type(value, str) - Uses the word "prove" instead of "assert" * static_assert_type(value, str) - Adds the word "static" in alongside "assert".

...

That's a reasonable concern, [...]. I'm happy to change the PR if

...

another name. I'll note though that cast() has the same potential

JelleZijlstra already did comment: there's consensus for problem, and I

...

haven't heard of confusion because of that.

-- David Foster | Seattle, WA, USA Contributor to TypedDict support for mypy

I'm also a little bit worried about confusion stemming from "assert" in the name. For instance, note that the recently added `assert_never` does actually perform an assert at runtime. I don't think `cast` really suffers from the same problem, since it doesn't have "assert" in the name. Recently there's been a bunch of discussion about the lines between runtime typing and static typing and I think it behooves us to try to avoid creating points of potential confusion. I liked the suggestion of `static_assert_type`. Another suggestion would be `check_type`. On Sun, 6 Feb 2022 at 16:08, Guido van Rossum wrote:

I for one have been confused by the usage of the term "assert" for this. In particular it took me a long time to be convinced that this has any value over just writing "assert False". So I think we should maybe take a step back and think hard about this.

On Sun, Feb 6, 2022 at 3:32 PM Jelle Zijlstra wrote:

...

I'd be curious to hear thoughts from others, but I'd prefer to stick with the assert_type() name. Several of us came up with the same name independently, so it's the most obvious name. While there is some potential for confusion, the function lives in the `typing` namespace, which should make it obvious that it's meant for static typing, not runtime checks.

El jue, 3 feb 2022 a las 7:51, David Foster () escribió:

...

On 1/23/22 4:39 PM, Jelle Zijlstra wrote:

...

https://github.com/python/cpython/pull/30843 is the draft CPython implementation. As with the others, any suggestions are welcome. [...]

It occurs to me that users of "assert_type()" - with that function name - may be surprised that it doesn't actually perform an assertion at runtime, considering that a regular "assert" statement *does* make a runtime check. Consider code like:

def parse_int(value) -> int: assert_type(value, str) # easily read incorrectly as: assert isinstance(value, str) return int(value)

I wonder if we might consider a word other than "assert", or maybe add the word "static" somewhere. Ideas:

* prove_type(value, str) - Uses the word "prove" instead of "assert" * static_assert_type(value, str) - Adds the word "static" in alongside "assert".

...

That's a reasonable concern, [...]. I'm happy to change the PR if

...

another name. I'll note though that cast() has the same potential

JelleZijlstra already did comment: there's consensus for problem, and I

...

haven't heard of confusion because of that.

-- David Foster | Seattle, WA, USA Contributor to TypedDict support for mypy

_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: guido@python.org

-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c... _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: hauntsaninja@gmail.com

On the contrary, pytype added `assert_type` because users came up with the idea and asked for it, as a way to make sure the typechecker was doing what they expected it to. Since the notion of python static typing is closely tied to the operation of the type checker, I would say `assert_type` is fine being in typing. martin On Wed, Feb 9, 2022 at 1:25 AM Никита Соболев wrote:

I had some time to think about this problem, since it affects multiple mine projects.

In my opinion this should not go into `typing` at all. As I see it, `typing` is for typing utilities that are useful for a wide range of users.

But, `assert_type` is only useful for maintainers of type-checkers and typed libraries (very small percent). With some *very limited* usage in the end code.

Maybe we can create a special package under https://github.com/python/typing and call it something like `advanced_type_utils`?

I see several pros: - It will be independent from CPython's release cycle - It will still be "official" - We can add more "advanced" features there without the fear that they might be misinterpreted by a wider range of users - We can still standardize it across type-checkers, the same way we do it for `typing_extensions`

Cons? - Harder visibility (It might be a plus as well, depending on the interpretation) - Extra dev-only dependency for libraries to test their types (I think we can live with that) - Possible complexity to support multiple Python versions (I am probably overthinking it)

Do others agree? :)

Best, Nikita Sobolev

ср, 9 февр. 2022 г. в 10:25, Shantanu Jain :

...

I'm also a little bit worried about confusion stemming from "assert" in the name. For instance, note that the recently added `assert_never` does actually perform an assert at runtime. I don't think `cast` really suffers from the same problem, since it doesn't have "assert" in the name. Recently there's been a bunch of discussion about the lines between runtime typing and static typing and I think it behooves us to try to avoid creating points of potential confusion.

I liked the suggestion of `static_assert_type`. Another suggestion would be `check_type`.

On Sun, 6 Feb 2022 at 16:08, Guido van Rossum wrote:

...

I for one have been confused by the usage of the term "assert" for this. In particular it took me a long time to be convinced that this has any value over just writing "assert False". So I think we should maybe take a step back and think hard about this.

On Sun, Feb 6, 2022 at 3:32 PM Jelle Zijlstra wrote:

...

I'd be curious to hear thoughts from others, but I'd prefer to stick with the assert_type() name. Several of us came up with the same name independently, so it's the most obvious name. While there is some potential for confusion, the function lives in the `typing` namespace, which should make it obvious that it's meant for static typing, not runtime checks.

El jue, 3 feb 2022 a las 7:51, David Foster () escribió:

...

On 1/23/22 4:39 PM, Jelle Zijlstra wrote:

...

https://github.com/python/cpython/pull/30843 is the draft CPython implementation. As with the others, any suggestions are welcome. [...]

It occurs to me that users of "assert_type()" - with that function name - may be surprised that it doesn't actually perform an assertion at runtime, considering that a regular "assert" statement *does* make a runtime check. Consider code like:

def parse_int(value) -> int: assert_type(value, str) # easily read incorrectly as: assert isinstance(value, str) return int(value)

I wonder if we might consider a word other than "assert", or maybe add the word "static" somewhere. Ideas:

* prove_type(value, str) - Uses the word "prove" instead of "assert" * static_assert_type(value, str) - Adds the word "static" in alongside "assert".

...

That's a reasonable concern, [...]. I'm happy to change the PR if

...

another name. I'll note though that cast() has the same potential

JelleZijlstra already did comment: there's consensus for problem, and I

...

haven't heard of confusion because of that.

-- David Foster | Seattle, WA, USA Contributor to TypedDict support for mypy

_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: guido@python.org

-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c... _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: hauntsaninja@gmail.com

_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: n.a.sobolev@gmail.com

_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: mdemello@google.com

How about `assume()` or `assume_type()` as a name? The reasoning would be you assume the type at runtime, but verify (prove) that assumption with a static type checker.

type_check(x, int) perhaps. martin On Mon, Feb 14, 2022 at 1:34 PM Anton Agestam wrote:

How about `assume()` or `assume_type()` as a name?

The reasoning would be you assume the type at runtime, but verify (prove) that assumption with a static type checker. _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: mdemello@google.com

Even though I did have initial objections I have grown to like the current term and I see no reason to change it. On Sun, Mar 6, 2022 at 18:33 Jelle Zijlstra wrote:

I'd like to get the assert_type proposal finished up. I think there's broad agreement that the idea is useful, but there are concerns that the assert_type() could be confusing, because people may assume it does a runtime assertion.

I see the problem, but I don't see any better alternatives at the moment. Here are the alternatives that have been proposed in this thread: - static_assert_type: Wordy, and confusing with C++ static_assert which does something different. - prove_type: Probably the best option, but "prove" isn't a word we've previously used with the Python type system. It sounds to me like we're branching into automated theorem proving. - assume, assume_type: This sounds to me like a directive to the type checker to narrow a type. - check_type, type_check: This suggests a runtime typecheck even more strongly than assert_type() does.

Also, the assert_type() name was independently invented by the pytype team and by Eric in https://github.com/python/typing/discussions/1030, suggesting that it's an obvious name for this concept.

What do others think? I'm happy to change the name if there's consensus for some other name.

El lun, 14 feb 2022 a las 14:24, Martin DeMello via Typing-sig (< typing-sig@python.org>) escribió:

...

type_check(x, int) perhaps.

martin

On Mon, Feb 14, 2022 at 1:34 PM Anton Agestam wrote:

...

How about `assume()` or `assume_type()` as a name?

The reasoning would be you assume the type at runtime, but verify (prove) that assumption with a static type checker. _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: mdemello@google.com

_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: jelle.zijlstra@gmail.com

_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: guido@python.org

-- --Guido (mobile)

On 3/7/22 2:23 PM, Alex Waygood wrote:

I agree with Jelle and Guido. The name isn't perfect, but I haven't seen any suggestions that seem better to me (and can't think of any myself). The function will be useful; I think it's time to move forward with this proposal.

Seems fine to me. (I'm one of the folks who was concerned with the assert_type() name.) In my own code, I'll probably opt to always use such an assert_type() function in qualified form, as `typing.assert_type()` (by using `import typing` rather than `from typing import assert_type`) since that will be more likely to be treated as "something that has to do with static typing" rather than a runtime assertion. Best, -- David Foster | Seattle, WA, USA Contributor to TypedDict support for mypy