On 24 May 2017 at 01:39, Paul Moore <p.f.mo...@gmail.com> wrote: > On 23 May 2017 at 16:20, Nick Coghlan <ncogh...@gmail.com> wrote: >> Taking that approach of just defining a helper API and expecting build >> backends to either use it or emulate it gives us some quite attractive >> properties: > > Making the output data part of a structured API (and by implication, > saying that backends shouldn't be writing to stdout directly at all) > would definitely improve the situation, IMO. Frankly, it seems likely > that the only real way we're going to get backend developers to > consider encodings is by having the "build output" as a string value > passed back via the API, rather than implied in the fact that backends > can write to stdout/err. It also squarely places the responsibility > for dealing with the question of displaying full-range Unicode output > to the user onto the frontend. > > However, it's a relatively big change to the PEP and there's a risk > that by endlessly reaching for perfection, we miss the chance to get > the PEP in at all (another lesson we should probably learn from PEP > 426!)
Yep, and that's also why I want to avoid trying to use it to improve the encoding handling situation - pip and other tools have to deal with the current mess regardless, and there's already likely to be some significant churn in this space as a result of the changes Victor and I have proposed for Python 3.7. As a result, I think adding in additional requirements here runs a significant risk of requiring build backend developers to do additional work to achieve nominal spec compliance without actually simplifying anything in practice for frontend developers. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
