> Implicit knowledge in your own head about what might or might not be a
> good idea to program is not the same thing as a specification.
> "type(x) is str" is a good specification in this context, while
> "string subclasses, but only if they're really str" does not.
> 
> And the reason why that is, is because the first specification allows
> server implementers to say, "your type is not str, so you are not
> conformant; go fix your code."   The second "specification" is just an
> invitation to (number of server implementations)*(number of string
> implementations) arguments about what conformance is.

You might argue about this all the way you want, but let me repeat it:
the interpreter already, implicitly, uses the "second specification" in
many of its internal routines (e.g. C implementations of stdlib
functions and types). Why do you think what is fine for the interpreter
and its stdlib is not fine for WSGI?

> Practicality beats purity, and explicit is better than implicit. 

And, ironically, you are arguing for a pure specification at the expense
of practicality. As for explicit/implicit, it isn't involved here: an
isinstance() test is as explicit as a type() equality test.