> After some thought, Nick came up with this solution.  The idea is that
> surrogateescape was originally accepted to allow roundtripping data
> from the OS and back when the OS considers it to be a "string" but
> python does not consider it to be "text".  When that's the case, we
> know what the encoding was used to attempt to construct the text in
> python.  If that same encoding is used to re-encode the data on the
> way back to the OS, then we're successfully roundtripping the data we
> were given in the first place.  So this is just applying the original
> goal to another API.

I think that outlook is a bit naïve. The text source is not always the
same as the text destination, i.e. your surrogateescape-decoded data may
come from a database or some JSON API, so there's no reason to think
that the end of the stdout pipe will share the same convention.

I'm myself quite partial to the "round-tripping" use case, but I'm not
sure we can solve it as bluntly. If it's merely for printing out data,
maybe we can an os.fsescape() function to allow for representation of
broken filenames.