Sorry, I didn't see this comment before pushing my changes to datamodel/constants, so they still reference TypeError.

In any event, is there some reason to stop at RuntimeWarning? I thought DeprecationWarning was supposed to give all the "code you cannot change" (third party packages) time to update themselves so nothing is using the error-prone code path by the time it becomes an actual error?

I can change it, but I'd prefer this to be an error eventually; RuntimeWarning is used in a few places, so the guidelines aren't clear, but in most cases it seems to boil down to either a mostly harmless thing where the warning tells you you asked Python to do something nonsensical/suboptimal (e.g. bad buffering configuration), and it chose to ignore you and do something valid/more optimal instead, or in the case of asyncio, a case that is probably an error (failing to await a coroutine), but the problem can't be detected until an unpredictable time after the problem occurred, so raising an exception isn't feasible at that point (the same way exceptions in del are suppressed). In most of these cases, Python can stumble along and ignoring the warning doesn't leave you doing anything wrong, just possibly suboptimal. In almost all cases, if NotImplemented is used in a boolean context, and there is no clearly valid way for Python to handle it (what should have delegated or raised TypeError becomes a return of True or False), thus my preference for (eventually) making it an error.