[python-committers] Re: [IMPORTANT] Preparations for 3.11.0 beta 1

2022-04-08 Thread Inada Naoki 
Thank you, Victor.

I had considered dropping (a) from the PEP. But I keep them because:

* I rushed to write PEP, before 3.11 beta.
* In the "Backward compatibility" section in the PEP, I want to
mention `locale.getencoding()` and `encoding="locale"`
* But they are not fixed in the main branch yet. So I need to include
what needs to be fixed in 3.11 in the PEP.

But for now, we are close to merge `locale.getencoding()`.
And I am afraid merging it before the PEP accepted even though it is
documented in the PEP...

Now I think the best way is:

* Withdraw the PEP submission temporarily.
* Implement `locale.getencoding()` and fix `encoding="locale"` in the
main branch.
* Remove them from the PEP.
* Resubmit the PEP.

And if the PEP is accepted, I want to do this in the 3.11 branch (even
though it will be beta already):

* Improve document about UTF-8 mode and EncodingWarning based on the PEP.
* Add (opt-in) EncodingWarning to `locale.getpreferredencoding()` and
`subprocess.Popen(text=True)`.

On Thu, Apr 7, 2022 at 9:42 PM Victor Stinner  wrote:
>
> IMO adding locale.getencoding() to Python 3.11 is not controversial
> and is useful even if PEP 686 is rejected. This function was discussed
> for 1 year (bpo-43510, bpo-43552, bpo-43557, bpo-47000) and there is
> an agreement that there is a need for this function.
>
> > Making `open(path, encoding="locale")` use locale encoding in UTF-8 mode 
> > (Python 3.10 used UTF-8)
>
> If someone explicitly opts in for the "locale encoding", it sounds
> surprising that the locale (encoding) is ignored and that UTF-8 is
> used if the Python UTF-8 Mode is enabled. I'm fine with this change.
> If you want to always UTF-8... Pass explicitly UTF-8:
>
> # no surprise, always decode file content from UTF-8
> json_file = open(filename, encoding="utf-8")
>
> --
>
> I will not comment PEP 686 here. It's being discussed on Discourse:
>
> * https://discuss.python.org/t/14435
> * https://discuss.python.org/t/14737
>
> Victor
>
> On Thu, Apr 7, 2022 at 5:35 AM Inada Naoki  wrote:
> >
> > Hi, Pablo.
> >
> > I just submitted the PEP 686 to the SC.
> > https://github.com/python/steering-council/issues/118
> >
> > In this PEP, I am proposing:
> >
> > a. Small improvement for UTF-8 mode in Python 3.11
> > b. Make UTF-8 mode default in Python 3.13.
> >
> > (a) is an important change for (b) so I included it in the PEP.
> > More precisely, (a) contains two changes:
> >
> > * Making `open(path, encoding="locale")` use locale encoding in UTF-8
> > mode (Python 3.10 used UTF-8)
> > * Add `locale.getencoding()` that is same to
> > `locale.getpreferredencoding(False)` but returns locale encoding even
> > in UTF-8 mode.
> >
> > These changes are important for (b).
> > But they are not a big change needing PEP.
> >
> > What should I do?
> >
> > * Do not merge anything until PEP accepted.
> > * Merge (a) without waiting PEP accepted.
> > * Merge (a) and remove it from the PEP.
> >
> > FWI, I and Victor are implementing `locale.getencoding()` for now.
> >
> > https://bugs.python.org/issue47000
> > https://github.com/python/cpython/pull/32068
> >
> > Regards,
> > --
> > Inada Naoki  
> > ___
> > python-committers mailing list -- [email protected]
> > To unsubscribe send an email to [email protected]
> > https://mail.python.org/mailman3/lists/python-committers.python.org/
> > Message archived at 
> > https://mail.python.org/archives/list/[email protected]/message/7E4QEKZ6HNDDPDL76LP3TBBKLAUQ7AHB/
> > Code of Conduct: https://www.python.org/psf/codeofconduct/
>
>
>
> --
> Night gathers, and now my watch begins. It shall not end until my death.



-- 
Inada Naoki  
___
python-committers mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/XVJEAF7S2OORL77QMLLQTWKHLRDFA3KH/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: [IMPORTANT] Preparations for 3.11.0 beta 1

2022-04-08 Thread Petr Viktorin 

On 08. 04. 22 9:51, Inada Naoki wrote:

Thank you, Victor.

I had considered dropping (a) from the PEP. But I keep them because:

* I rushed to write PEP, before 3.11 beta.
* In the "Backward compatibility" section in the PEP, I want to
mention `locale.getencoding()` and `encoding="locale"`
* But they are not fixed in the main branch yet. So I need to include
what needs to be fixed in 3.11 in the PEP.

But for now, we are close to merge `locale.getencoding()`.
And I am afraid merging it before the PEP accepted even though it is
documented in the PEP...

Now I think the best way is:

* Withdraw the PEP submission temporarily.
* Implement `locale.getencoding()` and fix `encoding="locale"` in the
main branch.
* Remove them from the PEP.
* Resubmit the PEP.


That shouldn't be necessary. If you're making these changes anyway, you 
can just add a note to the SC request that the 3.11 changes are being 
merged now. (I'll just do that myself now!)
Then update the PEP to say "This API was added in Python 3.11" instead 
of "will be added".



The SC did ask people to not submit PEPs that still have planned 
changes. I think that's because discussing the old version is 
essentially a waste of time, and if the change comes as a surprise it's 
frustrating.
But if the SC knows about the planned changes, it can adapt -- either 
delay its discussions, or just decide to discuss it anyway.


“Don't make *surprise* changes” is the main point, as I see it.

___
python-committers mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/2SYJFQUAQH7BU2LOJG6UKRMWZZZELPXG/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Consider adding a Tier 3 to tiered platform support

2022-04-08 Thread Marc-Andre Lemburg 
On 06.04.2022 20:48, Brett Cannon wrote:
> Last chance on whether my tier 3 proposal make sense! I will take silence as
> acceptance and plan to convert any current tier 2 platform with a single core
> dev to tier 3 and then ask the SC to approve/reject the list of platforms. I
> will also update the PEP about expectations of when things must be considered
> stable before b1, else a warning goes out that a platform risks being dropped 
> in
> the RC (regardless of tier).
> 
> I will also be filling out the tiers to include the vendor, but I will be 
> using
> `unknown` instead of `*` since I haven't come across the latter online while I
> come across the former regularly (e.g.
> https://doc.rust-lang.org/nightly/rustc/platform-support.html).

Could you please post the current proposal somewhere to read in
one complete piece ? It's become hard to figure out what is on
the table at the moment and the PR also doesn't appear to be
up to date:

https://github.com/python/peps/pull/2442/files

Thanks.

> On Fri, Apr 1, 2022 at 6:50 PM Victor Stinner  > wrote:
> 
> On Fri, Apr 1, 2022 at 11:19 PM Christian Heimes  > wrote:
> > How about:
> >
> > * a buildbot is required. For a transition period a public CI system,
> > that runs Python's test suite at least once per day, is also acceptable.
> >
> > * at least one active contributor who acts as a point of contact,
> > monitors CI and provides fixes in a timely fashion.
> 
> Sadly, I'm not sure that a regular contributor is enough to get fixes
> merged even fixes are written. Maybe it's better to require one core
> dev per Tier 3 platform.
> 
> What if tomorrow someone sets up a MinGW buildbot. Is it enough to
> promote MinGW as Tier 3? There are many MinGW patches awaiting in the
> bug tracker for *years* and nobody is available to review and merged
> them. (I didn't check recently, maybe some of them have been merged in
> the meanwhile?)
> 
> For the buildbot, IMO it's important that the whole test suite pass.
> I'm fine with skipping a large number of tests. But a single failure
> makes a buildbot really annoying, barely usuable, because buildbots
> are unable to say if a change adds more errors than previously. It's a
> boolean: either all tests pass, or "at least one test fails": you have
> to dig into logs to know the exact number :-(
> 
> Victor
> -- 
> Night gathers, and now my watch begins. It shall not end until my death.


-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Apr 08 2022)
>>> Python Projects, Coaching and Support ...https://www.egenix.com/
>>> Python Product Development ...https://consulting.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   https://www.egenix.com/company/contact/
 https://www.malemburg.com/

___
python-committers mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/NCRQHRMTQYXXNF2Y4OMNXOWD4HT4KNKU/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Consider adding a Tier 3 to tiered platform support

2022-04-08 Thread Brett Cannon 
On Fri, Apr 8, 2022 at 5:03 AM Marc-Andre Lemburg  wrote:

> On 06.04.2022 20:48, Brett Cannon wrote:
> > Last chance on whether my tier 3 proposal make sense! I will take
> silence as
> > acceptance and plan to convert any current tier 2 platform with a single
> core
> > dev to tier 3 and then ask the SC to approve/reject the list of
> platforms. I
> > will also update the PEP about expectations of when things must be
> considered
> > stable before b1, else a warning goes out that a platform risks being
> dropped in
> > the RC (regardless of tier).
> >
> > I will also be filling out the tiers to include the vendor, but I will
> be using
> > `unknown` instead of `*` since I haven't come across the latter online
> while I
> > come across the former regularly (e.g.
> > https://doc.rust-lang.org/nightly/rustc/platform-support.html).
>
> Could you please post the current proposal somewhere to read in
> one complete piece ? It's become hard to figure out what is on
> the table at the moment and the PR also doesn't appear to be
> up to date:
>
> https://github.com/python/peps/pull/2442/files


The PR is now up-to-date! For ease of reference, here's the critical part:

Support tiers
=

Platform support is broken down into *tiers*. Each tier comes with
different requirements which lead to different promises being made
about support.

To be promoted to a tier, steering council support is required and is
expected to be driven by team consensus. Demotion to a lower tier
occurs then the requirements of the current tier are no longer met for
a platform for an extended period of time based on the judgment of
the release manager or steering council. For platforms which no longer
meet the requirements of any tier by b1 of a new feature release, an
announcement will be made to warn the community of the pending removal
of support for the platform (e.g. in the b1 announcement). If the
platform is not brought into line for at least one of the tiers by the
first release candidate, it will be listed as unsupported in this PEP.

Tier 1
--

- `CI failures <
https://github.com/python/cpython/actions/workflows/build.yml?query=branch%3Amain+is%3Acompleted>`__
block releases.
- Changes which would break the ``main`` branch are not allowed to be
merged;
  any breakage should be fixed or reverted immediately.
- All core developers are responsible to keep ``main``, and thus these
  platforms, working.
- Failures on these platforms **block a release**.

 =
Target TripleNotes
 =
i686-pc-windows-msvc
x86_64-pc-windows-msvc
x86_64-apple-darwin  BSD libc, clang
x86_64-unknown-linux-gnu glibc, gcc
 =


Tier 2
--

- Must have a reliable buildbot.
- At least **two** core developers are signed up to support the platform.
- Changes which break any of these platforms are to be **fixed or
  reverted within 24 hours**.
- Failures on these platforms **block a release**.

=== ==
== 
Target Triple   Notes  Buildbot
  Contacts
=== ==
== 
aarch64-apple-darwinclang
https://buildbot.python.org/all/#/builders/725 Ned Deily, Ronald Oussoren,
Dong-he Na
aarch64-unknown-linux-gnu   glibc, gcc
https://buildbot.python.org/all/#/builders/125 Petr Viktorin, Victor Stinner

glibc, clang
https://buildbot.python.org/all/#/builders/234 Victor Stinner, Gregory P.
Smith
powerpcle-unknown-linux-gnu glibc, gcc
https://buildbot.python.org/all/#/builders/90  Petr Viktorin, Victor Stinner
x86_64-unknownlinux-gnu glibc, clang
https://buildbot.python.org/all/#/builders/441 Victor Stinner, Gregory P.
Smith
=== ==
== 


Tier 3
--

- Must have a reliable buildbot.
- At least **one** core developer is signed up to support the platform.
- No response SLA to failures.
- Failures on these platforms do **not** block a release.

=== ==
== 
Target Triple   Notes  Buildbot
  Contacts
=== ==
== 
aarch64-pc-windows-msvc
https://buildbot.python.org/all/#/builders/729 Steve Dower
powerpcle-unknown-linux-gnu glibc, clang
https://buildbot.python.org/all/#/builders/435 Victor Stinner
x86_64-unknown-freebsd  BSD libc, clang
https://buildbot.python.org/all/#/builders/172 Victor Stinner
=== ==
== 


All other platforms
---