Re: [Python-Dev] Aligning the packaging.python.org theme with the rest of the docs

[Nick Coghlan]

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

[Guido van Rossum]

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

[Brett Cannon]

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

[Mariatta Wijaya]

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

[Nick Coghlan]

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