1. WSGI is a *Python* spec, not a *CPython* spec, so CPython implementation details have little bearing on how the spec should work.

Most non-CPython implementations have a native string type optimized for their runtime or VM (i.e. Jython and IronPython), and thus have *different* implementation-dependent details of what constitutes a "native" string, other than that it has type 'str' as seen by Python code.  (See my previous point about people bringing these sorts of implicit assumptions to the table!)

(Also, as you may or may not be aware, WSGI supports Python 2.1, mainly for Jython's sake at the time, and in Python 2.1 there was *no such thing* as a subclass of 'str' to begin with.)

2. The specific practical goal of WSGI is interoperability, *not* programmer convenience.  (Says so right in the PEP.)

3. You are free to patch wsgiref's Headers class to *accept* non-str values (as long as they are converted to conforming strings in the process) and to make any proposals you like for future versions of WSGI or another interop protocol via the Web-SIG, so this entire discussion has been moot for some time now.

4. The explicit-vs-implicit is about the contract defined in the spec (making explicit what, precisely, is required of both parties), not the type test.

5. Since this discussion is moot (see point 3), we'll have to agree to disagree here.  Whether you (or I!) like what the spec says is not what matters: wsgiref is the *reference library* for the specification, and therefore must conform to the actual spec, not what any of us would like the spec to be.

Heck, I tried to add some *much* more minor amendments to PEP 333 than this about three or four months ago, and Guido said he'd reject the whole PEP if I tried!  That's why we have PEP 3333 instead of a slightly-amended PEP 333.  This particular bikeshed was painted six years ago, so let's get on with the actual bicycling already.