[Python-Dev] PEP 538: Coercing the legacy C locale to a UTF-8 based locale (original) (raw)
Nick Coghlan ncoghlan at gmail.com
Mon Mar 6 11:25:00 EST 2017
- Previous message (by thread): [Python-Dev] PEP 538: Coercing the legacy C locale to a UTF-8 based locale
- Next message (by thread): [Python-Dev] PEP 538: Coercing the legacy C locale to a UTF-8 based locale
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 6 March 2017 at 00:39, INADA Naoki <songofacandy at gmail.com> wrote:
I prefer just "locale-aware" / "locale-independent" (application | library | function) to "locale-aware C/C++ application" / "C/C++ independent" here.
Good point, I'll fix that in the next update.
Backporting to Python 3.6.0 > --------------------------- > > If this PEP is accepted for Python 3.7, redistributors backporting the > change > specifically to their initial Python 3.6.0 release will be both allowed and > encouraged. However, such backports should only be undertaken either in > conjunction with the changes needed to also provide a suitable locale by > default, or else specifically for platforms where such a locale is already > consistently available. >
If it's really encouraged, how about providing patch officially, or backport it in 3.6.2 but disabled by default? Some Python users (including my company) uses pyenv or pythonz to build Python from source. This PEP and PEP 540 are important for them too.
For PEP 540, the changes are too intrusive to consider it a reasonable candidate for backporting to an earlier feature release, so for that aspect, we'll all be waiting for 3.7.
For this PEP, while it's deliberately unobtrusive to make it more backporting friendly, 3.7 isn't that far away, and I didn't think to seriously pursue this approach until well after the 3.6 beta deadline for new features had passed. With it being clearly outside the normal bounds of what's appropriate for a cross-platform maintenance release, that means the only folks that can consider it for earlier releases are those building their own binaries for more constrained target environments.
I can definitely make sure the patch is readily available for anyone that wants to apply it to their own builds, though (I'll upload it to both the Python tracker issue and the downstream Fedora Bugzilla entry).
I also wouldn't completely close the door on the idea of classifying the change as a bug fix in CPython's handling of the C locale (and hence adding to a latter 3.6.x feature release), but I think the time to pursue that would be after we've had a chance to see how folks react to the redistributor customizations. I think it will be universally positive (because the status quo really is broken), but it also wouldn't be the first time I've learned something new and confusing about the locale subsystem only after releasing software that relied on an incorrect assumption about it :)
Cheers, Nick.
-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20170307/9f083feb/attachment.html>
- Previous message (by thread): [Python-Dev] PEP 538: Coercing the legacy C locale to a UTF-8 based locale
- Next message (by thread): [Python-Dev] PEP 538: Coercing the legacy C locale to a UTF-8 based locale
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]