Re: [Python-Dev] PEP 538 (review round 2): Coercing the legacy C locale to a UTF-8 based locale
On 28 May 2017 at 16:46, INADA Naoki wrote: > Now I approve the PEP 538. > > It's side-effect (just set LC_CTYPE envvar) seems simple enough and > moderate enough. > > Locale coercion will save people from unwanted mojibake (escaped string) > and locale warning will navigate people to configure locale properly. > > And there are configure options and envvar option to disable it for people > who want to continue to use C locale explicitly. > > Congrats, Nick! Thank you! And thank you for your work in reviewing the PEP - I think the accepted version is a significant improvement over the more intrusive design I originally proposed downstream in Fedora :) Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 538 (review round 2): Coercing the legacy C locale to a UTF-8 based locale
Now I approve the PEP 538. It's side-effect (just set LC_CTYPE envvar) seems simple enough and moderate enough. Locale coercion will save people from unwanted mojibake (escaped string) and locale warning will navigate people to configure locale properly. And there are configure options and envvar option to disable it for people who want to continue to use C locale explicitly. Congrats, Nick! On Sat, May 27, 2017 at 4:19 PM, Nick Coghlan wrote: > On 24 May 2017 at 02:34, Nick Coghlan wrote: >> On 23 May 2017 at 18:38, INADA Naoki wrote: >>> Would you add example demonstrates how coercing LANG helps people? >> >> I'm honestly not sure it does - I think it's an assumption I added to >> the PEP early on, and never actually tested. Looking at it more >> closely now, all of the interpreter level checks are specifically for >> LC_CTYPE, and experimenting with "LANG=C LC_CTYPE=C.UTF-8" indicates >> that coercing only LC_CTYPE is still enough to fix the GNU readline >> encoding compatibility problem covered in >> https://www.python.org/dev/peps/pep-0538/#considering-locale-coercion-independently-of-utf-8-mode >> >> So I'll take another pass through the implementation this weekend, and >> simplify it to only set LC_CTYPE regardless of whether it's using >> C.UTF-8, C.utf8, or UTF-8 as the target locale. Assuming that doesn't >> uncover any hidden problems with the idea, I'll then update the PEP to >> match. > > I've now gone through this, and as far as I can tell, setting only > LC_CTYPE is sufficient to handle all the scenarios that the PEP aims > to address, and has fewer potential side effects than setting both > LC_CTYPE and LANG. > > Accordingly, I've updated both the PEP and the implementation to only > set LC_CTYPE and leave LANG alone: > > * PEP: > https://github.com/python/peps/commit/12cecb05489e74a36a11c17e8d0b1e36e3768bda > * Implementation: > https://github.com/python/cpython/pull/659/commits/939ba0a77d4b52a04315c129f9db89b90c0532cd > > Regards, > Nick. > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Aligning the packaging.python.org theme with the rest of the docs
On 28 May 2017 at 06:54, Guido van Rossum wrote: > Are you also going to stop others from using the psf theme? I think it would definitely make sense to discourage the use of this particular theme for projects that aren't relatively directly affiliated with the PSF - there are plenty of other pip-installable high contrast themes out there that aren't closely associated with a particular backing organisation. The one Jon was originally considering for the PyPA docs was Alabaster, which is now the default theme in Sphinx 1.3+: https://alabaster.readthedocs.io/en/latest/ So I think it would be appropriate to include a sentence like the following in the README for psf-docs-theme: "Please limit use of this theme to projects which are closely affiliated with the Python Software Foundation, and have permission from either the CPython core development team or the PSF itself for such use. For other projects looking for a simple, high contrast, pip installable Sphinx theme, we recommend the Alabaster theme used by default in Sphinx 1.3+." Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Aligning the packaging.python.org theme with the rest of the docs
Are you also going to stop others from using the psf theme? On May 27, 2017 11:35, "Brett Cannon" wrote: > > > On Fri, 26 May 2017 at 21:28 Nick Coghlan wrote: > >> Hi folks, >> >> Over on https://github.com/pypa/python-packaging-user-guide/ >> pull/305#issuecomment-304169735 >> we're looking to update the theming of packaging.python.org to match >> that of the language documentation at docs.python.org. >> >> Doing that would also entail updating the documentation of the >> individual tools and services (pip, pypi, setuptools, wheel, etc) to >> maintain consistency with the main packaging user guide, so Jon has >> tentatively broken the theme out as a (not yet published anywhere) >> "pypa-theme" package to make it easier to re-use across multiple >> projects. >> >> The question that occurred to me is whether or not it might make more >> sense to instead call that package "psf-docs-theme", to reflect that >> it's intended specifically for projects that are legally backed by the >> PSF, and that general Python projects looking for a nice, >> high-contrast, theme should consider using an org independent one like >> Alabaster instead. >> >> Thoughts? Should we stick with pypa-theme as the name? Switch to >> psf-docs-theme? Publish both, with pypa-theme adding PyPA specific >> elements to a more general psf-docs-theme? >> > > If we're going to share the theme beyond docs.python.org it makes sense > to have a shared theme under the Python org that can easily be reused by > multiple sets of documentation. > > As for the name, the psf-docs-theme seems fine with me. > > -Brett > > >> >> Cheers, >> Nick. >> >> P.S. In case folks aren't aware of the full legal arrangements here: >> in addition to the informal "Python Packaging Authority" designation, >> there's also a formally constituted PSF Packaging Working Group that >> provides the legal connection back to the PSF. That means the >> relationship between PyPA and the PSF ends up being pretty similar to >> the one between python-dev and the PSF, where there's no direct PSF >> involvement in day to day development activities, but the PSF provides >> the legal and financial backing needed to sustainably maintain popular >> community-supported software and services. >> >> Part of my rationale for suggesting the inclusion of "psf" in the >> package name is to make it clear that the intent would be to create a >> clear and distinctive "trade dress" for the documentation of directly >> PSF backed projects: >> https://en.wikipedia.org/wiki/Trade_dress#Protection_for_ >> electronic_interfaces_and_websites >> >> Future requests to use the theme (beyond CPython and the PyPA) could >> then be run through the PSF Trademarks committee, as with requests to >> use the registered marks. >> >> Whereas if we go with pypa-theme, then that would just be a >> non-precedent-setting agreement between PyPA and CPython to share a >> documentation theme, without trying to define any form of >> documentation trade dress for the PSF in general. >> >> -- >> Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia >> ___ >> Python-Dev mailing list >> Python-Dev@python.org >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: https://mail.python.org/mailman/options/python-dev/ >> brett%40python.org >> > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > guido%40python.org > > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Aligning the packaging.python.org theme with the rest of the docs
On Fri, 26 May 2017 at 21:28 Nick Coghlan wrote: > Hi folks, > > Over on > https://github.com/pypa/python-packaging-user-guide/pull/305#issuecomment-304169735 > we're looking to update the theming of packaging.python.org to match > that of the language documentation at docs.python.org. > > Doing that would also entail updating the documentation of the > individual tools and services (pip, pypi, setuptools, wheel, etc) to > maintain consistency with the main packaging user guide, so Jon has > tentatively broken the theme out as a (not yet published anywhere) > "pypa-theme" package to make it easier to re-use across multiple > projects. > > The question that occurred to me is whether or not it might make more > sense to instead call that package "psf-docs-theme", to reflect that > it's intended specifically for projects that are legally backed by the > PSF, and that general Python projects looking for a nice, > high-contrast, theme should consider using an org independent one like > Alabaster instead. > > Thoughts? Should we stick with pypa-theme as the name? Switch to > psf-docs-theme? Publish both, with pypa-theme adding PyPA specific > elements to a more general psf-docs-theme? > If we're going to share the theme beyond docs.python.org it makes sense to have a shared theme under the Python org that can easily be reused by multiple sets of documentation. As for the name, the psf-docs-theme seems fine with me. -Brett > > Cheers, > Nick. > > P.S. In case folks aren't aware of the full legal arrangements here: > in addition to the informal "Python Packaging Authority" designation, > there's also a formally constituted PSF Packaging Working Group that > provides the legal connection back to the PSF. That means the > relationship between PyPA and the PSF ends up being pretty similar to > the one between python-dev and the PSF, where there's no direct PSF > involvement in day to day development activities, but the PSF provides > the legal and financial backing needed to sustainably maintain popular > community-supported software and services. > > Part of my rationale for suggesting the inclusion of "psf" in the > package name is to make it clear that the intent would be to create a > clear and distinctive "trade dress" for the documentation of directly > PSF backed projects: > > https://en.wikipedia.org/wiki/Trade_dress#Protection_for_electronic_interfaces_and_websites > > Future requests to use the theme (beyond CPython and the PyPA) could > then be run through the PSF Trademarks committee, as with requests to > use the registered marks. > > Whereas if we go with pypa-theme, then that would just be a > non-precedent-setting agreement between PyPA and CPython to share a > documentation theme, without trying to define any form of > documentation trade dress for the PSF in general. > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecate invalid ctypes call protection on Windows
Thanks all. Documentation has been updated in https://bugs.python.org/issue30470 On May 23, 2017 9:13 PM, "Victor Stinner" wrote: Sure, make your change and then update libffi! Victor Le 23 mai 2017 18:19, "Steve Dower" a écrit : > On 23May2017 1212, Victor Stinner wrote: > >> 2017-05-22 13:17 GMT-05:00 Steve Dower : >> >>> Once the special protection is removed, most of these cases will become >>> OSError due to the general protection against segmentation faults. >>> >> >> It didn't know that ctypes on Windows had a special protection against >> programming errors. I'm not aware of such protection Linux. If you >> call a function with the wrong number of arguments, it's likely to >> crash or return random data. >> >> I guess that the point is to help debugging. But since Python 3.6, >> faulthandler now registers a Windows exception handler and so it able >> to dump the Python traceback on any Windows exception: >> https://docs.python.org/dev/library/faulthandler.html#faulthandler.enable >> >> So I think that it's now fine to remove the ctypes protection. Just >> advice (remind? ;-)) users to enable faulthandler: python3 -X >> faulthandler, or call faulthandler.enable(). (You might want to use a >> log file for that on Windows, depends on the use case.) >> > > faulthandler is already recommended in the docs, and the existing SEH > protection for access violations will remain (since that is independent of > libffi). > > I'll be honest, I have appreciated the functionality in the past, but it > really isn't good practice and getting rid of it will be an overall > benefit. Technically even the segfault protection isn't a great idea, since > you really do end up in an unknown state with regards to memory page > allocations, but it's better than crashing all the way out. > > Cheers, > Steve > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ mariatta.wijaya%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 538 (review round 2): Coercing the legacy C locale to a UTF-8 based locale
On 24 May 2017 at 02:34, Nick Coghlan wrote: > On 23 May 2017 at 18:38, INADA Naoki wrote: >> Would you add example demonstrates how coercing LANG helps people? > > I'm honestly not sure it does - I think it's an assumption I added to > the PEP early on, and never actually tested. Looking at it more > closely now, all of the interpreter level checks are specifically for > LC_CTYPE, and experimenting with "LANG=C LC_CTYPE=C.UTF-8" indicates > that coercing only LC_CTYPE is still enough to fix the GNU readline > encoding compatibility problem covered in > https://www.python.org/dev/peps/pep-0538/#considering-locale-coercion-independently-of-utf-8-mode > > So I'll take another pass through the implementation this weekend, and > simplify it to only set LC_CTYPE regardless of whether it's using > C.UTF-8, C.utf8, or UTF-8 as the target locale. Assuming that doesn't > uncover any hidden problems with the idea, I'll then update the PEP to > match. I've now gone through this, and as far as I can tell, setting only LC_CTYPE is sufficient to handle all the scenarios that the PEP aims to address, and has fewer potential side effects than setting both LC_CTYPE and LANG. Accordingly, I've updated both the PEP and the implementation to only set LC_CTYPE and leave LANG alone: * PEP: https://github.com/python/peps/commit/12cecb05489e74a36a11c17e8d0b1e36e3768bda * Implementation: https://github.com/python/cpython/pull/659/commits/939ba0a77d4b52a04315c129f9db89b90c0532cd Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com