[IMPORTANT] Preparations for 3.11.0 beta 1
Hi everyone,
We have approximately one month until feature freeze and for 3.11.0b1 to be released. I wanted to take this time to share some planning and considerations with you. Please, read carefully these points as they are important.
3.11.0b1 is scheduled for Friday, 2022-05-06, which is after the PyCon US sprints. As the sprints normally end with a considerable amount of PRs getting merged and the buildbots having a hard time, I may need to move the release before or after to accommodate for this and to prevent the release from going haywire. I will share updates with you as they become available.
The latest alpha releases have been quite challenging. We had a considerable number of release blockers and issues that were raised just a couple of days before the release. Please, check the release blockers on bpo/Github as much as you can and make sure these are resolved before the release date. Any release blockers for 3.11 will block feature freeze. If this happens, the main branch will be blocked and only PRs fixing the blockers will be allowed in that time.
Important!! Please, if you are planning to commit a big chunk of code/ a new big refactor/ a new big feature/ a PEP implementation within this month, please let me know (an email works) so we can be on top of things in the release team and so I can keep an eye on regressions.
Any regression at the time of beta freeze will potentially result in the release team being forced to revert commits and PRs. This means that if we need to revert a new feature or similar it may be delayed to 3.12, so be sure to not commit unstable code as much as is humanly possible.
Please, reach out to me if you have any questions, comments or if you want to discuss anything.
I want to thank you all for your understanding and collaboration :)
Kind regards from rainy London, Your friendly release team
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 tolocale.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 <songofacandy@gmail.com>
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:
Victor
On Thu, Apr 7, 2022 at 5:35 AM Inada Naoki <songofacandy@gmail.com> 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 tolocale.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 <songofacandy@gmail.com>
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/7... Code of Conduct: https://www.python.org/psf/codeofconduct/
-- Night gathers, and now my watch begins. It shall not end until my death.
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()andencoding="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 fixencoding="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()andsubprocess.Popen(text=True).
On Thu, Apr 7, 2022 at 9:42 PM Victor Stinner <vstinner@python.org> 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:
Victor
On Thu, Apr 7, 2022 at 5:35 AM Inada Naoki <songofacandy@gmail.com> 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 tolocale.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 <songofacandy@gmail.com>
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/7... 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 <songofacandy@gmail.com>
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()andencoding="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 fixencoding="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.
On Fri, Apr 8, 2022 at 6:05 PM Petr Viktorin <encukou@gmail.com> wrote:
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".
I fixed issues in Python 3.11 and updating the PEP as you suggested. Thank you. https://github.com/python/peps/pull/2525/files
-- Inada Naoki <songofacandy@gmail.com>
On Thu, Apr 7, 2022 at 5:35 AM Inada Naoki <songofacandy@gmail.com> wrote:
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.
It's easier to approve or reject a PEP if all changes target the same Python version. I'm not sure that (a) changes require a PEP, they are mostly bugfixes and uncontroversial enhancements.
Victor
participants (4)
-
Inada Naoki -
Pablo Galindo Salgado -
Petr Viktorin -
Victor Stinner