-
Notifications
You must be signed in to change notification settings - Fork 219
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PEP updates #31
PEP updates #31
Conversation
- Remove the UCS-4 requirement in favor of pip/wheel's new SOABI support. - Mandate that manylinux1 extensions *not* link against libpythonX.Y.so.1, for complicated compatibility-related reasons. - Update link for the docker images to their new PyPA home.
UCS-4 ABI. But then, in between the PEP's initial acceptance and its | ||
implementation, ``pip`` and ``wheel`` gained first-class support for | ||
tracking and checking this aspect of ABI compatibility for the | ||
relevant CPython versions, which is a better solution. So we now allow |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure this history of the PEP is required.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PEP's normally spend a lot of time talking about other things that were considered but rejected, etc.; given that we're actually changing the PEP after it was accepted I think it's a good idea to record the reasoning.
I agree with all of the changes. In a couple places (inline comments), I thought that the tone was perhaps a little bit too colloquial, but that's just a minor nitpick. |
--------------------- | ||
|
||
All versions of CPython 2.x, plus CPython 3.0-3.2, can be built in two | ||
ABI-incompatible modes: one where Unicode is stored using UCS-2, and |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's actually stored as UTF16 - see https://mail.python.org/pipermail/python-dev/2008-July/080892.html
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm... just going to ignore this I think :-). (But thank you for the feedback!) The distinction truly doesn't matter for our current purposes, and the configure script and C API both call it UCS-2, so... I tried a few ways of getting this information in there but they were all super clunky.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I would have just done 'a build using the --enable-unicode=ucs4
configure flag stores unicode in UCS-4 / UTF-32 format, whereas a build using --enable-unicode=ucs2
stores unicode in UTF-16. '
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, that works. Used that, and then tweaked it further :-)
Sounds like there's consensus, and Nick's agreed, so putting this in and sending up to pep-editors |
support.
libpythonX.Y.so.1, for complicated compatibility-related reasons.