Martin,

That was exactly my first approach. What made me change my mind is that 

   i) it is also fairly hacky (one might rightfully object that it is the isinstance(x, unicode) tests that should be changed)

   ii) it is now a hack spread over a dozen files, instead of the site.py alone.

   iii) the alterations in those files are executed even in the case of built-in unicode support, thus increasing the risk of introducing a regression in the stdlib.

In the end I was a bit loath to alter quite a few of the stdlib modules (including some of the "core" ones) for a rather infrequent case. My solution, on the other hand, is such that in the regular case of built-in unicode support those modules are not touched at all, thus reducing the risk of introducing a regression in the stdlib.

Still, if you guys do think that the maintainability risk due to the hackiness of my suggestion exceeds the potential benefits, it might be better to split the issue (and the patch) into two: one for the autoconf and interpreter, and one for the stdlib. In this way, the patch for autconf and interpreter (which should be less controversial) might be accepted sooner, while we bide our time until we come up with a better solution for the stdlib.