Alex Waygood

Adding `reveal_type` calls to the example confirms that mypy is picking a different overload with the alias-to-Any version: https://mypy-play.net/?mypy=latest&python=3.11&flags=strict&gist=8b3429d9daae0e46ebc64d5aae592513

We haven't done a typeshed sync in a while; we might want to do one before the next release. The automated one two weeks ago failed due to merge conflicts...

> It might be worth cherry picking [python/typeshed#11353](https://github.com/python/typeshed/pull/11353) No need — it's already in the release-1.9 branch (we did two typeshed syncs in quick succession)

almost certainly due to https://github.com/python/mypy/pull/16942

Primer summary: - 10 new errors in user code - 1 existing error goes away - 4 existing errors have their error message change slightly The next step is to...

Here's the traceback if you use an uncompiled version of mypy from the `master` branch (`RecursionError`s cause mypyc to segfault without a traceback): Traceback ```pytb (venv) (master) % mypy -c...

Thanks for the great bug report! It looks like this still repros if you use `--new-type-inference`, as well.

As is often the case with mypyc segfaults, it seems this is due to a `RecursionError`. Here's the last part of the stack trace if you use an uncompiled install...

> This started occurring recently after we upgraded from `1.0.0` to `1.2.0`. Would you be able to check to see if it reproduces with the latest version of mypy (1.5.1)?...

This is a valid crash report (since mypy should never crash on syntactically valid Python code). But the quick fix is "don't do that" — it doesn't really make much...