Re: [Python-Dev] What version is an extension module binary compatible with

[Martin Panter]

On 30 March 2017 at 15:31, Nick Coghlan  wrote:
> On 29 March 2017 at 02:18, Paul Moore  wrote:
>> On 28 March 2017 at 12:24, Miro Hrončok  wrote:
>>> I'd like some clarification on what ABI compatibility we can expect.
>>>  * Should the ABI be stable across patch releases (so calling
>>> PySlice_AdjustIndices from an existing macro would be a bug)?
>>>  * Should the ABI be forward-compatible within a minor release (so modules
>>> built for 3.6.0 should be usable with 3.6.1, but not vice versa)?
>>>  * Or should we expect the ABI to change even across patch releases?
>>
>> Given that binary wheels are built against a specific minor version
>> (3.6, 3.5, ...) I would expect the ABI to be consistent over a minor
>> release. That would fit with my expectations of the compatibility
>> guarantees on patch releases.
>>
>> So I from what you describe, I'd consider this as a bug. Certainly, if
>> someone built a C extension as a wheel using Python 3.6.1, it would be
>> tagged as compatible with cp36, and pip would happily use it when
>> installing to a Python 3.6.0 system, where it would fail.
>
> Right, this is the main problem - while "build against the X.Y.0
> headers" is useful advice, it's not something we've ever explicitly
> stated, and it's not something we can reasonably expect all providers
> of pre-built binary modules to do.
>
> Instead, it makes sense to explicitly strengthen the ABI guarantees
> within CPython maintenance releases, and add some automated testing to
> avoid accidental changes and oversights (similar to the pending test
> to ensure magic number stability for cached bytecode files)

There's a website that has nice reports of ABI compatibility of
various packages and might useful for testing. It shows up the added
PySlice_AdjustIndices function in 3.6.1, along with PySlice_Unpack
(and some changes to internal names, so probably not such a problem).
https://abi-laboratory.pro/tracker/compat_report/python/3.6.0/3.6.1/496a4/abi_compat_report.html
___
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] What version is an extension module binary compatible with

[Nick Coghlan]

On 29 March 2017 at 02:18, Paul Moore  wrote:
> On 28 March 2017 at 12:24, Miro Hrončok  wrote:
>> I'd like some clarification on what ABI compatibility we can expect.
>>  * Should the ABI be stable across patch releases (so calling
>> PySlice_AdjustIndices from an existing macro would be a bug)?
>>  * Should the ABI be forward-compatible within a minor release (so modules
>> built for 3.6.0 should be usable with 3.6.1, but not vice versa)?
>>  * Or should we expect the ABI to change even across patch releases?
>
> Given that binary wheels are built against a specific minor version
> (3.6, 3.5, ...) I would expect the ABI to be consistent over a minor
> release. That would fit with my expectations of the compatibility
> guarantees on patch releases.
>
> So I from what you describe, I'd consider this as a bug. Certainly, if
> someone built a C extension as a wheel using Python 3.6.1, it would be
> tagged as compatible with cp36, and pip would happily use it when
> installing to a Python 3.6.0 system, where it would fail.

Right, this is the main problem - while "build against the X.Y.0
headers" is useful advice, it's not something we've ever explicitly
stated, and it's not something we can reasonably expect all providers
of pre-built binary modules to do.

Instead, it makes sense to explicitly strengthen the ABI guarantees
within CPython maintenance releases, and add some automated testing to
avoid accidental changes and oversights (similar to the pending test
to ensure magic number stability for cached bytecode files)

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] PEP 545: Python Documentation Translations

[Terry Reedy]

On 3/29/2017 4:13 PM, Julien Palard via Python-Dev wrote:


Gladly, but … how? I'm very new to all those process and have now idea
on how I can get in touch with PSF lawyers.


https://www.python.org/about/legal/
"If you have any questions, please send them to the legal mailing list 
at: le...@python.org."



--
Terry Jan Reedy


___
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] What version is an extension module binary compatible with

[Nathaniel Smith]

On Wed, Mar 29, 2017 at 8:22 AM, Paul Moore  wrote:
> On 28 March 2017 at 17:31, Nathaniel Smith  wrote:
>> IMO this is a bug, and depending on how many packages are affected it might
>> even call for an emergency 3.6.2. The worst case is that we start getting
>> large numbers of packages uploaded to pypi that claim to be 3.6.0 compatible
>> but that crash like crash with an obscure error when people download them.
>
> Has anyone logged this on bugs.python.org? There's nothing in the
> Fedora bug referenced by the OP that indicates they've done so.

I didn't see one, so: https://bugs.python.org/issue29943

-n

-- 
Nathaniel J. Smith -- https://vorpus.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] PEP 545: Python Documentation Translations

[Brett Cannon]

On Wed, 29 Mar 2017 at 13:13 Julien Palard  wrote:

> Hi Brett, thanks for the feedback!
>
>
>
>
>
>
>
>
>
> Please check with the PSF that this is what we really want.
>
>
> Gladly, but … how? I'm very new to all those process and have now idea on
> how I can get in touch with PSF lawyers.
>
> What kind of support does Read the Docs have for translations? I have no
> active plans to push for this but it has been idea in the back of my head
> for a while so it would be good to know if such a move would make this
> easier or harder.
>
> Read the Docs support translations [1]_, quoting them:
>
> > To support this, you will have one parent project and a number
> > of projects marked as translations of that parent. Let’s use
> > phpmyadmin as an example.
>
> > The main phpmyadmin project is the parent for all translations.
> > Then you must create a project for each translation, for
> > example phpmyadmin-spanish. You will set the Language for
> > phpmyadmin-spanish to Spanish. In the parent projects
> > Translations page, you will say that phpmyadmin-spanish is a
> > translation for your project.
>
> > This has the results of serving:
> > - phpmyadmin at http://phpmyadmin.readthedocs.io/en/latest/
> > - phpmyadmin-spanish at http://phpmyadmin.readthedocs.io/es/latest/
>
> Which is nice as it's almost the same syntax the PEP proposes for paths:
> /{language_tag}/{version_tag}.
> Their language tags are simplified too (redundency removed (fr-FR → fr))
> but not lowercased, and they
> use underscore "instead of" dashes as a separator, see for example:
>
> - https://docs.phpmyadmin.net/fr/latest/
> - https://docs.phpmyadmin.net/pt_BR/latest/
>
> while the PEP proposes /pt-br/ instead.
>
> .. [1] Project with multiple translations
>(
> https://docs.readthedocs.io/en/latest/localization.html#project-with-multiple-translations
> )
>

Should we just match what Read the Docs does then?
___
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] Issue with _thread.interrupt_main (29926)

[Martin Panter]

On 29 March 2017 at 00:40, Terry Reedy  wrote:
> [. . .] Eryk Sun suggested a patch for Windows, (and
> the possibility of using pthread_kill).  Can you possibly do one for *nix?
> This is out of my ballpark, but the bug (relative to console behavior) is a
> nuisance.

I'll try to find time, but no promises.
___
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 545: Python Documentation Translations

[Julien Palard via Python-Dev]

Hi Jakub,

Typos

Fixed, thanks.

* Julien Palard , 2017-03-29, 07:47:
>It's redundant to display both language and country code if they're the same,
>for example: "de-DE" or "fr-FR".

This wording is unfortunate. It seems to imply that you can meaningfully
compare a language code and a territory code for equality. This is not the
case. For example, Belarusian (language code "be") is mainly spoken in Belarus
(country code "by"), not in Belgium (country code "be").

Thanks for noticing, would the intented meaning is "when they add no 
distinguishing information", is it better like:

==
We may drop the region subtag when it does does not add
distinguishing information, for example: "de-DE" or "fr-FR".
(Although it might make sense, respectively meaning "German as
spoken in Germany" and "French as spoken in France"). But when
the region subtag actually adds information, for example "pt-BR"
for "Portuguese as spoken in Brazil", it should be kept.
==

?

Bests,
--
Julien Palard
https://mdk.fr___
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 545: Python Documentation Translations

[Jakub Wilk]

Typos:

english -> English
Febrary -> February
insted -> instead
redundent -> redundant

* Julien Palard , 2017-03-29, 07:47:
It's redundant to display both language and country code if they're the same, 
for example: "de-DE" or "fr-FR".


This wording is unfortunate. It seems to imply that you can meaningfully 
compare a language code and a territory code for equality. This is not the 
case. For example, Belarusian (language code "be") is mainly spoken in Belarus 
(country code "by"), not in Belgium (country code "be").


--
Jakub Wilk
___
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 545: Python Documentation Translations

[Julien Palard via Python-Dev]

Hi Brett, thanks for the feedback!

Please check with the PSF that this is what we really want.

Gladly, but … how? I'm very new to all those process and have now idea on how I 
can get in touch with PSF lawyers.

What kind of support does Read the Docs have for translations? I have no active 
plans to push for this but it has been idea in the back of my head for a while 
so it would be good to know if such a move would make this easier or harder.

Read the Docs support translations [1]_, quoting them:

> To support this, you will have one parent project and a number
> of projects marked as translations of that parent. Let’s use
> phpmyadmin as an example.

> The main phpmyadmin project is the parent for all translations.
> Then you must create a project for each translation, for
> example phpmyadmin-spanish. You will set the Language for
> phpmyadmin-spanish to Spanish. In the parent projects
> Translations page, you will say that phpmyadmin-spanish is a
> translation for your project.

> This has the results of serving:
> - phpmyadmin at http://phpmyadmin.readthedocs.io/en/latest/
> - phpmyadmin-spanish at http://phpmyadmin.readthedocs.io/es/latest/

Which is nice as it's almost the same syntax the PEP proposes for paths: 
/{language_tag}/{version_tag}.
Their language tags are simplified too (redundency removed (fr-FR → fr)) but 
not lowercased, and they
use underscore "instead of" dashes as a separator, see for example:

- https://docs.phpmyadmin.net/fr/latest/
- https://docs.phpmyadmin.net/pt_BR/latest/

while the PEP proposes /pt-br/ instead.

.. [1] Project with multiple translations
(https://docs.readthedocs.io/en/latest/localization.html#project-with-multiple-translations)

--
Julien Palard
[https://mdk.fr](https://mdk.fr/)___
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 545: Python Documentation Translations

[Brett Cannon]

Sounds good overall! I only have one thing to suggest in regards to the
license, two grammar tweaks, and a question.

On Wed, 29 Mar 2017 at 08:10 Julien Palard via Python-Dev <
python-dev@python.org> wrote:

> [SNIP]
> Sources of translated documentation will be hosted in the Python
> organization on GitHub: https://github.com/python/.  Contributors will
> have to sign the Python Contributor Agreement (CLA) and the license
> will be the PSF License.
>

Please check with the PSF that this is what we really want. In the past the
suggestion has been to **not** use the PSF license with all of its
historical baggage but instead use something like Apache. But since IANAL
we really should ask the PSF what the best license for new code is.


> [SNIP]
> The CLA bot may be used on the translation repositories, but with a
> limited effect as local coordinators may synchronize themselves with
> translations from an external tool, like transifex, and loose track
> of who translated what in the process.
>

"loose" -> "lose"


>
> [SNIP]
> Other tools may be used later https://pontoon.mozilla.org/
> and http://zanata.org/
>

"be used later like".


> [SNIP]
>
> Create sphinx-doc Language Switcher
> ---
>
> Highly similar to the version switcher, a language switcher must be
> implemented.  This language switcher must be configurable to hide or
> show a given language.
>
> The language switcher will only have to update or add the language
> segment to the path like the current version switcher does.  Unlike
> the version switcher, no preflight are required as destination page
> always exists (translations does not add or remove pages).
> Untranslated (but existing) pages still exists, they should however be
> rendered as so, see `Enhance Rendering of Untranslated and Fuzzy
> Translations`_.
>

What kind of support does Read the Docs have for translations? I have no
active plans to push for this but it has been idea in the back of my head
for a while so it would be good to know if such a move would make this
easier or harder.

-Brett
___
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] Misc/NEWS entries for Python 3.7a1

[Brett Cannon]

On Tue, 28 Mar 2017 at 23:36 INADA Naoki  wrote:

> On Tue, Mar 28, 2017 at 11:07 PM, Ned Deily  wrote:
> > On Mar 28, 2017, at 08:49, INADA Naoki  wrote:
> >> Currently, changelog of Python 3.7a1 [1] contains changes between
> >> 3.6b1 and 3.7a1.
> >> So lot's of bugfixes are listed twice or more in changelog.
> >> For example, "bpo-28258: Fixed build with Estonian locale..." are
> >> listed under 3.5.3rc1,
> >> 3.6.0b2 and 3.7.0a1.
> >>
> >> [1] https://docs.python.org/3.7/whatsnew/changelog.html#changelog
> > [...]
> >
> > Thanks for noticing. Misc/NEWS is always somewhat problematic.  As you
> probably know, the Core Workflow SIG, led by Brett, is working on a
> long-term solution to generating Misc/NEWS, a solution that should be
> available soon.  One of the duties of the release manager is to "edit"
> Misc/NEWS; I was planning to wait for the new Misc/NEWS solution and for
> more of the conversion to Git/GitHub to settle to do anything major to the
> master (i.e. 3.7) version.  There have already been some major merge
> mistakes for the 3.6.x Misc/NEWS.  I would recommend not to worry too much
> about master's Misc/NEWS right now.  I may do some cleaning up before the
> new Misc/NEWS process is introduced but I will also be reviewing it prior
> to each of the preview releases, which start later this year.
> >
> > --
> >   Ned Deily
> >   n...@python.org -- []
> >
>
> I forgot to mention about it.
> I have seen three preview pull requests about new NEWS handling.  All
> of them are quite large.
> That's one reason why I suggest removing some sections / entries from NEWS
> now.
> I thought reducing changelog size may help the transition.
>
> If I was wrong, let's stop discussion until transition.
> I want to help workflow team.  I don't want to disturb them.
>

I'm planning on make a decision on the tooling this week with the hope we
can start the transition by the end of April so that maybe everything can
be cleaned up by PyCon US.
___
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] What version is an extension module binary compatible with

[Paul Moore]

On 28 March 2017 at 17:31, Nathaniel Smith  wrote:
> IMO this is a bug, and depending on how many packages are affected it might
> even call for an emergency 3.6.2. The worst case is that we start getting
> large numbers of packages uploaded to pypi that claim to be 3.6.0 compatible
> but that crash like crash with an obscure error when people download them.

Has anyone logged this on bugs.python.org? There's nothing in the
Fedora bug referenced by the OP that indicates they've done so.

Paul
___
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

[Python-Dev] PEP 545: Python Documentation Translations

[Julien Palard via Python-Dev]

Hi.

Here's PEP 545, ready to be reviewed!
This is the follow-up to the "PEP: Python Documentation Translations" thread on 
python-ideas [1]_,
itself a follow-up of the "Translated Python documentation" thread on 
python-dev [2]_.

This PEP describes the steps to make existing and future translations of the 
Python documentation official and accessible on docs.python.org.

You can read it rendered here https://www.python.org/dev/peps/pep-0545/ or 
inline here, I'll happily get your feedback.


PEP: 545
Title: Python Documentation Translations
Version: $Revision$
Last-Modified: $Date$
Author: Victor Stinner ,
Inada Naoki ,
Julien Palard 
Status: Draft
Type: Process
Content-Type: text/x-rst
Created: 04-Mar-2017

Abstract


The intent of this PEP is to make existing translations of the Python
Documentation more accessible and discoverable. By doing so, we hope
to attract and motivate new translators and new translations.

Translated documentation will be hosted on python.org. Examples of
two active translation teams:

* http://docs.python.org/fr/: French
* http://docs.python.org/ja/: Japanese

http://docs.python.org/en/ will redirect to http://docs.python.org/.

Sources of translated documentation will be hosted in the Python
organization on GitHub: https://github.com/python/. Contributors will
have to sign the Python Contributor Agreement (CLA) and the license
will be the PSF License.

Motivation
==

On the French ``#python-fr`` IRC channel on freenode, it's not rare to
meet people who don't speak English and so are unable to read the
Python official documentation. Python wants to be widely available
to all users in any language: this is also why Python 3 supports
any non-ASCII identifiers:
https://www.python.org/dev/peps/pep-3131/#rationale

There are a least 3 groups of people who are translating the Python
documentation to their native language (French [16]_ [17]_ [18]_,
Japanese [19]_ [20]_, Spanish [21]_) even though their translations
are not visible on d.p.o. Other, less visible and less organized
groups, are also translating the documentation, we've heard of Russian
[26]_, Chinese and Korean. Others we haven't found yet might also
exist. This PEP defines rules describing how to move translations on
docs.python.org so they can easily be found by developers, newcomers
and potential translators.

The Japanese team has (as of March 2017) translated ~80% of the
documentation, the French team ~20%. French translation went from 6%
to 23% in 2016 [13]_ with 7 contributors [14]_, proving a translation
team can be faster than the rate the documentation mutates.

Quoting Xiang Zhang about Chinese translations:

I have seen several groups trying to translate part of our official
doc. But their efforts are disperse and quickly become lost because
they are not organized to work towards a single common result and
their results are hold anywhere on the Web and hard to find. An
official one could help ease the pain.

Rationale
=

Translation
---

Issue tracker
'

Considering that issues opened about translations may be written in
the translation language, which can be considered noise but at least
is inconsistent, issues should be placed outside `bugs.python.org
`_ (b.p.o).

As all translation must have their own github project (see `Repository
for Po Files`_), they must use the associated github issue tracker.

Considering the noise induced by translation issues redacted in any
languages which may beyond every warnings land in b.p.o, triage will
have to be done. Considering that translations already exist and are
not actually a source of noise in b.p.o, an unmanageable amount of
work is not to be expected. Considering that Xiang Zhang and Victor
Stinner are already triaging, and Julien Palard is willing to help on
this task, noise on b.p.o is not to be expected.

Also, language team coordinators (see `Language Team`_) should help
with triaging b.p.o by properly indicating, in the language of the
issue author if required, the right issue tracker.

Branches


Translation teams should focus on last stable versions, and use tools
(scripts, translation memory, …) to automatically translate what is
done in one branch to other branches.

.. note::
Translation memories are a kind of database of previously translated
paragraphs, even removed ones. See also `Sphinx Internationalization
`_.

The three currently stable branches that will be translated are [12]_:
2.7, 3.5, and 3.6. The scripts to build the documentation of older
branches needs to be modified to support translation [12]_, whereas
these branches now only accept security-only fixes.

The development branch (master) should have a lower translation priority
than stable branches. But docsbuild-scripts should build it anyway so
it is possible for a team to work on it to be ready for the next
release.

Hosti