Maybe we can just remove __del__? Since the argument is for internal use only anyway, I don't think there is much value in keeping the methods. (Would need an allowlist entry, though, probably.)

That might be good, yes. I'm not sure what value we get from putting __del__ methods in typeshed. I think a slightly better approach could be to pretend it takes no arguments, which would still need a stubtest entry.

I think stubtest actually already doesn't care whether __del__ exists in a stub or not; I think it's specifically excluded

After a quick grep: We have 16 instances of __del__ in stdlib, 8 of which are in asyncio. I'd say, let's get rid of them and see whether stubtest complains.

After a quick grep: We have 16 instances of __del__ in stdlib, 8 of which are in asyncio. I'd say, let's get rid of them and see whether stubtest complains.

Sounds good! I'm pretty confident stubtest won't complain, because of https://github.com/python/mypy/blob/544e6ce119ec6bdd5eabab53a433264c98dc7d9c/mypy/stubtest.py#L1377

One reason to keep it: https://docs.python.org/3/reference/datamodel.html#object.__del__ says

If a base class has a del() method, the derived class’s del() method, if any, must explicitly call it to ensure proper deletion of the base class part of the instance.

A type checker or other kind of linter might want to enforce this rule, but to do so, it needs to know whether __del__ exists in the base class. So I do think there is value in having these methods in typeshed.

And relatedly, removing __del__ methods from typeshed would mean that a derived class that does super().__del__() would get a false positive from a type checker, because there is no object.__del__.

One reason to keep it: https://docs.python.org/3/reference/datamodel.html#object.__del__ says

If a base class has a del() method, the derived class’s del() method, if any, must explicitly call it to ensure proper deletion of the base class part of the instance.

A type checker or other kind of linter might want to enforce this rule, but to do so, it needs to know whether __del__ exists in the base class. So I do think there is value in having these methods in typeshed.

In that case, we might want to remove it from stubtest's IGNORABLE_CLASS_DUNDERS frozenset

In that case, we might want to remove it from stubtest's IGNORABLE_CLASS_DUNDERS frozenset

Agree. For this PR though, I think I'd prefer to just pretend the _warn argument doesn't exist, since no users should be calling it and it exists only to early-bind the warn function. (The problem it guards against is that when __del__ is called, the module globals may already have been cleared.)

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉