What do we do if we're writing stubs for a library that really does invalidly declare a special method? It's happened before. We'd be in a tough spot there: we'd either have to noqa the lint error (due to it ) or allowlist the stubtest error. It might be pretty confusing for a new contributor that they get a CI error whichever thing they do?

What do we do if we're writing stubs for a library that really does invalidly declare a special method? [...] ]It might be pretty confusing for a new contributor that they get a CI error whichever thing they do?

We've had "unfixable" cases like that, I can namely remember around __all__ including names that don't exists. I personally think this is one of those rare cases where the best thing to do is to noqa it with a link to a report upstream.

I'd be very surprised, but if we add stubs for a library that does it on purpose, and often. Let's say overloads builtin dunders to add params and explicitly calls those methods instead of using keywords (del, in, repr, etc...). Then we could disable that rule for that stub (similarly to how we disable rules for proto generated stubs)

In other words, I think it's a rare/niche enough case and we have an escape hatch in case it does happen.

This has (not suprisingly) conflicts after merging #13306.

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