A couple comments: 1) Would it make sense to provide a way for build tools to specify what encoding they use (e.g. if not using the default), instead of changing their encoding to conform to a standard? It seems like that could be easier, although I know this doesn't address problems like non-conforming tools.
2) In terms of debugging, in cases where there are encoding-related errors, it would help if the overall system made it easy to pinpoint which parts of the system are at fault (using good error handling, diagnostic messages, etc). --Chris On Tue, May 23, 2017 at 10:04 AM, Thomas Kluyver <tho...@kluyver.me.uk> wrote: > On Tue, May 23, 2017, at 04:20 PM, Nick Coghlan wrote: >> Up to this point, I've been in favour of both 1b and 2b, since they're > > Noted. > >> However, I also realised that there's a potential third way to handle >> this problem: design a Python level API that allows front ends to use >> more structured data formats (e.g. JSON) for communication between the >> frontend and their backend shim. >> >> In particular, I'm thinking we could move the current >> "config_settings" dict onto something like a "build context" object >> that, *even in Python 2*, offers a Unicode "outstream" and >> "errstream", which the backend is then expected to use rather than >> writing to sys.stdout/err directly. That context could also provide a >> Python 3 style "run()" API for subprocess invocation that implemented >> the preferred stream handling behaviour for subprocess invocation >> (including applying the "backslashreplace" error handler regardless of >> version) > > I'm not really compelled by this so far: > _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
