-
Notifications
You must be signed in to change notification settings - Fork 225
PEP updates #31
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
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.