I'd like to propose making the error message when subclassing typing.NewType much more understandable. Currently it looks like:

TypeError: NewType.__init__() takes 3 positional arguments but 4 were given

But I think we could do much better by adding mro_entries to the class and then just having that raise a TypeError telling users they cannot subclass NewType and they are probably looking for NewType('Subclass', OlderType). I'd be happy to patch this myself if this sounds like a good idea.

This seems like a good idea to me.

I will send a PR for others to judge :)

I'd be happy to patch this myself if this sounds like a good idea.

Oh, please, go ahead! :)
Would be happy to review.

Do you have evidence that people make this particular mistake often? And that the suggested solution is indeed what they should use? Why would you want to subclass UserId?

Do we have examples of other error messages split across two lines like this?

Do you have evidence that people make this particular mistake often? And that the suggested solution is indeed what they should use? Why would you want to subclass UserId?

I was just trying to implement something that I thought had a non-obvious error message and isn't necessarily initially obvious if you have the idea that NewType creates a new type/class. The documentation suggests this is what you should be doing instead of subclassing it
342e800#diff-8a0f115fde6769c122b771b6d0eca184c4580f7b5fabe2f0b0579c679424364fR101-R113

Do we have examples of other error messages split across two lines like this?

No if you want me to remove it thats fine by me.

Weird, the docs you cite claims

   # Also does not typecheck
   ProUserId = NewType('ProUserId', UserId)

but when I try it, it works at runtime and passes mypy (even with --strict) and also pyright.

So maybe those docs are incorrect? I can't find anything in PEP-484 about this.

In any case I'd drop the newline in the message -- other "Did you mean" errors don't have those.

So maybe those docs are incorrect? I can't find anything in PEP-484 about this.

Mypy even has an explicit test that NewType of NewType should work: https://github.com/python/mypy/blob/f96446ce2f99a86210b21d39c7aec4b13a8bfc66/test-data/unit/check-newtype.test#L162-L165

I tend to agree with this behavior. This allows us to create complex type-safe DSLs:

from typing import NewType

UserId = NewType('UserId', int)
ProUserId = NewType('ProUserId', UserId)

x: ProUserId = ProUserId(UserId(1))

Mypy is happy with that!

I will open a new issue about incorrect docs.

Turns out modern docs already have this problem fixed: https://docs.python.org/3/library/typing.html#newtype

New changeset f391f9b by James Hilton-Balfe in branch 'main':
bpo-46170: Improve the error message when subclassing NewType (GH-30268)
f391f9b