<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 6 March 2017 at 00:39, INADA Naoki <span dir="ltr"><<a href="mailto:songofacandy@gmail.com" target="_blank">songofacandy@gmail.com</a>></span> wrote:<br>> I prefer just "locale-aware" / "locale-independent" (application |<br>
> library | function)<br>> to "locale-aware C/C++ application" / "C/C++ independent" here.<br><br></div><div class="gmail_quote">Good point, I'll fix that in the next update.<br></div><div class="gmail_quote"><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">> Backporting to Python 3.6.0<br>
> ---------------------------<br>
><br>
> If this PEP is accepted for Python 3.7, redistributors backporting the<br>
> change<br>
> specifically to their initial Python 3.6.0 release will be both allowed and<br>
> encouraged. However, such backports should only be undertaken either in<br>
> conjunction with the changes needed to also provide a suitable locale by<br>
> default, or else specifically for platforms where such a locale is already<br>
> consistently available.<br>
><br>
<br>
</span>If it's really encouraged, how about providing patch officially, or<br>
backport it in 3.6.2<br>
but disabled by default?<br>
Some Python users (including my company) uses pyenv or pythonz to<br>
build Python from source. This PEP and PEP 540 are important for them too.<br></blockquote><div><br></div><div>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.<br></div><div><br></div><div>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.<br><br>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).<br><br></div><div>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 :)<br></div><div><br></div><div>Cheers,<br></div><div>Nick.<br></div></div><br>-- <br><div class="gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>