On 6 February 2016 at 20:35, Marius Gedminas <mar...@gedmin.as> wrote: > On Sat, Feb 06, 2016 at 03:04:48PM +1000, Nick Coghlan wrote: >> That means the only folks that seem likely to miss out on pre-built >> binaries this way would be Python 2.7 pyenv users. > > And people who run build Python 2.7 with './configure && make && make install'
If folks can handle building their own Python, handling building other projects isn't that much worse (although stumbling across FORTRAN dependencies may still be a surprise). > Why does upstream Python default to UCS-2 builds on Linux anyway? That default long predates my time on the core development team, but my guess is that it was influenced by that also being the default for Windows and the JVM, before folks were really aware of the problems that arise when using UTF-16 as the internal encoding for working with code points outside the Basic Multilingual Plane. By the time that perspective changed, the fix was to eliminate the distinction (and significantly reduce the memory cost of correctness), rather than to just change the default. > FWIW the rationale Pyenv gave when they rejected a bug asking for UCS-4 > builds by default was "we prefer to follow upstream defaults". In this case, the old defaults are dubious, but the upstream fix eliminated the relevant setting. Historically, it didn't really matter, since very few people were building their own Python for Linux. However, if that was pyenv's only reason for rejecting a switch to wide unicode builds, it may be worth trying again, this time pointing them to PEP 513 and the wide-build default for Python 2.7 wheels in the manylinux build environment. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
