`directives_type_checking.py`: do not assert that type checkers must ignore all type errors in `if not TYPE_CHECKING` blocks by AlexWaygood · Pull Request #2210 · python/typing

rather try to make it easier to add the missing "implicit" parts to the spec

In what way should it be easier? It's really not that hard: make a post on Discuss, wait a week, submit a PR. The level of difficulty is really determined entirely by how controversial the clarification is, which seems like roughly how it should be.

I would want to avoid stripping the conformance tests of all of the assumptions

When there are things codified in the conformance suite but not mentioned in the spec (which implies "not mentioned in a PEP", which implies a lower level of community scrutiny), and there is a type checker which has a reasoned perspective on how it should work that differs from the conformance suite assertion, innovation should not be constrained simply by "well, everyone else has always done it this way, and someone landed a conformance suite test at some point asserting that". That said, I think that innovation (at least, innovation that wants to claim conformance!) should be constrained by whether the community / typing council feel it's actually a good idea! So type checkers should continue to push back on unspecified assumptions encoded in the conformance suite, and there are (at least) two possible outcomes to that: we can say "oh yeah, it does seem reasonable to try different approaches here" and adjust/remove the assertion, or we can say "no, actually, this seems like a point where consistency has value, and we should clarify the spec." I think this particular PR falls into the latter case, but I don't agree that we should adopt an attitude that whatever the conformance suite happens to assert is de facto specified.