Changelog for Release 1.18 by KevinRK29 · Pull Request #19818 · python/mypy

@KevinRK29

Added initial changelog for the 1.18 release

@pre-commit-ci

BobTheBuidler

hauntsaninja

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's worth having the top-level section mentioning the overall amount of performance speed up (maybe get a number relative to 1.17 and 1.10)


This feature was contributed by Jelle Zijlstra (PR [19678](https://github.com/python/mypy/pull/19678)).

### Mypy Improvements

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

### Mypy Improvements
### Mypy Performance Improvements
### Documentation Updates

- Add idlemypyextension to IDE integrations (CoolCat467, PR [18615](https://github.com/python/mypy/pull/18615))
- Update stubinfo for latest typeshed (Shantanu, PR [19771](https://github.com/python/mypy/pull/19771))

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: this should be under "Other Notable Improvements" (it affects the diagnostics users get)

hauntsaninja

- More detailed checking of type objects in stubtest (Stephen Morton, PR [18251](https://github.com/python/mypy/pull/18251))
- Support running stubtest in non-UTF8 terminals (Stanislav Terliakovm, PR [19085](https://github.com/python/mypy/pull/19085))

### Bug Fixes

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure what the difference between this section and Other Notable Improvements is (many of the things in the other one would count as bug fixes)

ilevkivskyi

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI changelog is a very serious document, that is actually read by humans. Please show some respect to mypy users and actually spend some time writing it.

This is not acceptable.


### `--allow-redefinition-new`

Exposes an (experimental) command‑line flag to control whether subclass `__new__` redefinitions are accepted. This was previously an internal toggle; it’s now publicly documented via --allow-redefinition-new so advanced projects can fine‑tune behavior without internal flags

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, what? This flag has nothing to do with __new__. Also this paragraph should have a brief description of the semantics, and probably an example of use (e.g. with an if statement). Also it probably makes sense to add a section to mypy docs.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That documentation is pretty good, yes. Maybe it should be edited to remove the "experimental" framing.

It certainly has nothing to do with __new__.


Exposes an (experimental) command‑line flag to control whether subclass `__new__` redefinitions are accepted. This was previously an internal toggle; it’s now publicly documented via --allow-redefinition-new so advanced projects can fine‑tune behavior without internal flags

This feature was contributed by Ivan Levkivskyi (PR [19796](https://github.com/python/mypy/pull/19796)).

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The core feature was contributed by Jukka, not by me.

- Denser representation for common scalars (int, str)
- Lower GC pressure when reading caches
- Guardrails around constructor cache emission (compatibility)
- Expose --fixed-format-cache if compiled

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All these details are not needed, just remove them.

### Fixed‑Format Cache (experimental)

Introduces an optional binary fixed‑format cache that’s both smaller and notably faster to load than the JSON/orjson cache. Local measurements on the PR show ~2.5× faster deserialization than orjson and reviewer benchmarks report a ~35% cached import speedup on a large workload; the flag is currently hidden/opt‑in while we iterate. Follow‑ups further shrink/optimize the format and reduce GC overhead during loads.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please stop using LLMs, sorry, but this looks horrible.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apologies, I didn't have much context into it, so I wrote something down with the help of it as a placeholder before Jukka could get a look to write something for it. It was also 3 am for me, so I wasn't thinking straight 😅

JukkaL

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for preparing a draft changelog! I'm going to merge this now and prepare a follow-up PR with various edits. This way is faster than leaving review feedback here.

KevinRK29 added a commit that referenced this pull request

Sep 11, 2025
(cherry picked from commit 9ae3e9a)