FWIW, we've seen a large shift in our userbase from UCS-2 to UCS-4 as Anaconda Python becomes the defacto Python2 interpreter in the sciences.
We still ship both UCS-2 and UCS-4 as well. -Brian > On Feb 6, 2016, at 5:35 AM, Marius Gedminas <mar...@gedmin.as> wrote: > >> On Sat, Feb 06, 2016 at 03:04:48PM +1000, Nick Coghlan wrote: >>> On 6 February 2016 at 03:53, Nate Coraor <n...@bx.psu.edu> wrote: >>>> On Fri, Feb 5, 2016 at 12:46 PM, Nathaniel Smith <n...@pobox.com> wrote: >>>> >>>>> On Feb 5, 2016 8:47 AM, "Nate Coraor" <n...@bx.psu.edu> wrote: >>>>> >>>> [...] >>>>> - Add SOABI tags to platform-specific wheels built for Python 2.X (Pull >>>>> Request >>>>> #55, Issue #63, Issue #101) >>>> >>>> I can't quite untangle all the documents linked from this PR, so let me >>>> ask here :-). Does this mean that python 2.x extension wheels now can and >>>> should declare whether they're assuming the 16- or 32-bit Unicode ABI >>>> inside >>>> the abi field? And if so, should PEP 513 be updated to allow for both >>>> options to be used with manylinux1? (Right not manylinux1 just >>>> implies/requires a UCS4 build, for older pythons where this matters.) >>> >>> It isn't declared, wheel determines the ABI of the interpreter upon which >>> the wheel is being built and tags it accordingly. So yes, I think a PEP 513 >>> update is appropriate. >> >> +1 from me, since it's a genuine bug in the current specification. >> >>> As to whether the manylinux1 Docker images should >>> include UCS-2 Pythons is a separate question, though. If there's interest, I >>> can provide statistics of how many of Galaxy's UCS-2 Linux eggs were >>> downloaded over time. >> >> While I'd be interested in those stats, my initial inclination is to >> say "No" to including narrow Unicode runtimes in the build >> environment, as: >> >> 1. Python 2.7 narrow Unicode builds really don't handle code points >= >> 65,535 correctly >> 2. Python 3.3+ doesn't have the narrow/wide distinction >> 3. Canopy users will presumably be getting most of their binaries from >> Enthought, not PyPI >> >> 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' > > Why does upstream Python default to UCS-2 builds on Linux anyway? > > FWIW the rationale Pyenv gave when they rejected a bug asking for UCS-4 > builds by default was "we prefer to follow upstream defaults". > > Marius Gedminas > -- > Some people around here wouldn't recognize > subtlety if it hit them on the head. > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
