> Hm, 20% isn't so bad, but one of the arguments for NewType was that it "disappears" at runtime -- which the current version does, but the class-based version doesn't quite.

NewType was described originally in https://github.com/python/typing/issues/189 and the resulting PEP text landed in https://github.com/python/typing/pull/226/files.

I find the 20% performance impact non-ideal but ultimately worth it because:
- it solves the issue described in this bug;
- it allows us to implement issubclass/isinstance in the future if we so choose;
- it also potentially allows us to chain NewType.

Since we can't fully rely on `from __future__ import annotations` to side-step the performance cost, we don't really have a different option than to change it. The alternative is to leave it as is which makes it a non-composable pseudo-type unlike the others.

Currently adoption of NewType is relatively low, in part due to the feature's obscurity and partially because of its limits. Slower instantiation performance will at worst keep the adoption low, but it can potentially bring more users to NewType since it becomes less hacky.

I'm +1 to converting to a class as done by the PR.


> Right now I don't have the cycles to think about this deeply. Maybe a few weeks after I'm back from vacation (~August 8) I will have more time.

Sorry, I overeagerly already merged the change to `main`. Let's hold off with the 3.10 backport until you had time to think about it. If we decide against the change after all, reverting on `main` should have no negative impact since we're pre-alpha 1.