Mailman 3 March 2021 - python-committers

CI tests are broken
by Mark Shannon 31 Mar '21

31 Mar '21

Hi, My PR tests are failing seemingly due to some bug in enum.rst Which might be caused by https://github.com/python/cpython/pull/22392 (that's the superficial cause, it might not be the root cause). Example failure: https://github.com/python/cpython/pull/25069 https://github.com/python/cpython/pull/25069/checks?check_run_id=2235991560 Why are we merging PRs that fail the CI tests? Why is that even allowed? Cheers, Mark.

5 7

PEP 644 Accepted -- Require OpenSSL 1.1.1 or newer
by Pablo Galindo Salgado 30 Mar '21

30 Mar '21

Hi Christian, Thank you for submitting PEP 644 (Require OpenSSL 1.1.1). After evaluating the situation and discussing the PEP, the Steering Council is happy with the PEP, and hereby accepts it. The SC is of the opinion that this change will make it considerable easier to maintain the extension modules that depend on OpenSSL while allowing us to leverage the new APIs and improvements in the future. As indicated in the PEP, OpenSSL 1.1.1 is the default variant and version of OpenSSL on almost all supported platforms and distributions almost all known Major CI providers provide images with OpenSSL 1.1.1, so we believe this has the right balance to improve the situation without causing major impact or breakage. Nevertheless, the Steering Council would like to see this change reflected properly in the documentation, What's New (linking against the new instructions here: https://docs.python.org/3.10/using/unix.html#custom-openssl) and release manager notices so this is properly communicated to our users. The Steering Council also thanks Christian for his patience explaining different aspects of the PEP, including in the PEP some extra requested information and for considering the concerts raised. Congratulations, Christian! With thanks from the whole Python Steering Council, Pablo Galindo Salgado

1 0

Python Language Summit 2021 Signups Are Now Open
by Łukasz Langa 22 Mar '21

22 Mar '21

I’m happy to announce that we’ve opened the sign-up forms for the 2021 Python Language Summit! TL;DR When: Tuesday, May 11, 2021 (4 hours) and Wednesday, May 12, 2021 (4 hours). Exact times TBD depending on attendee timezones. Where: Online via Zoom (link will be sent via email to attendees) Co-chairs: Mariatta Wijaya & Łukasz Langa Blogger: Joanna Jablonski Sign up to attend and actively participate: https://forms.gle/cgmGnmQMDhD2mhHY8 <https://forms.gle/cgmGnmQMDhD2mhHY8> (closes after March 22nd, 2021 AoE) Propose a topic: https://forms.gle/Jui9mxsHrB4fVvAB8 <https://forms.gle/Jui9mxsHrB4fVvAB8> (closes after March 22nd, 2021 AoE) To get an idea of past Python Language Summits, you can read these blog posts: 2020: Python Software Foundation News: The 2020 Python Language Summit <https://pyfound.blogspot.com/2020/04/the-2020-python-language-summit.html> 2019: http://pyfound.blogspot.com/2019/05/the-2019-python-language-summit.html <http://pyfound.blogspot.com/2019/05/the-2019-python-language-summit.html> 2018: The 2018 Python Language Summit [LWN.net] <https://lwn.net/Articles/754152/> 2017: The 2017 Python Language Summit [LWN.net] <https://lwn.net/Articles/723251/> Do I need to sign up if I’m a Python core developer? Yes please! While in the past we have limited attendance to 50 people, this time, due to virtual format, we will be a bit more flexible, but will still keep it small and manageable. We aren’t planning to go beyond 80 participants. Please register to reserve your space. Can I sign up if I’m not a Python core developer? Yes you can. In the past, we had quite a number of participants who were not Python core devs. Among them were maintainers and representatives from BeeWare, CircuitPython, PSF board member, PyCharm, PyPA, etc. Register if you want to participate. Note that until you hear back from us, your attendance is not confirmed. As explained in the question above, our “space” is more flexible than usual, but in the interest of maintaining a vigorous discussion space, we might still be unable to invite everyone who signs up. What kind of topics are covered? Python Language Summit is a special event with very specific audience: Python core developers. Ideally your topic is not an “announcement” or “project status” but rather something that will encourage further discussion and questions. The more controversial, the better. An open issue, group of issues, or a PEP that is awaiting decision are all good topics to propose. You can also further explain why this is better discussed in person instead of online. According to last year’s feedback, our audience prefer more discussions and shorter talks. Who can present a talk? Anyone, even if you’re not a Python core developer. However, please understand that we will have to be selective as space and time are limited. In particular, we are prioritizing active core contributors, as well as those who we believe will be able to improve the quality of the discussions at the event and bring a more diverse perspective to core Python developers. Note that your topic is not confirmed until you hear back from us. Code of Conduct PyCon’s Code of Conduct <https://us.pycon.org/2020/about/code-of-conduct/> applies and will be enforced. Thanks! @mariatta <https://discuss.python.org/u/mariatta> & @ambv <https://discuss.python.org/u/ambv>

2 3

PyCon US passes for core devs
by Ewa Jodlowska 18 Mar '21

18 Mar '21

Hi! As some of you may have seen, PyCon US <https://us.pycon.org/2021/> launched registration. We have dedicated passes set aside for core devs as part of our financial aid program. If you are interested in a free pass to PyCon US, please apply for financial aid via your dashboard once you create a login: https://us.pycon.org/2021/users/dashboard/ *Deadline to apply is March 26, 2021* Ewa Jodlowska Executive Director Python Software Foundation 415-319-5237 ewa(a)python.org

3 3

Publish better than md5sums of Python builds?
by Julien Palard 17 Mar '21

17 Mar '21

Hi, Someone on Mastodon had me noticed that: => https://www.python.org/downloads/release/python-392/ gives the md5 sum of Python builds, and that we should probably do better. What about sha256? Has it been discussed already? Bests, -- [Julien Palard](https://mdk.fr)

11 12

Accepting PEP 624 (Remove Py_UNICODE encoder APIs)
by Thomas Wouters 16 Mar '21

16 Mar '21

Hi Inada, Thank you for submitting PEP 624 (Remove Py_UNICODE encoder APIs). The Steering Council is happy to accept it, but we do have two conditions. We want to make sure that the documentation is clear on what is deprecated, and when they are scheduled to be removed. For example, PyUnicode_TransformDecimalToASCII is itself not currently marked as deprecated (although the section header does mention the deprecation, that is easy to miss), PyUnicode_TranslateCharmap is scheduled for removal in 4.0, and PyUnicode_AsUnicode has two deprecation notices, one mentioning removal in 3.10 and one in 3.12. We would also like to make sure users who need to migrate off of these APIs have the information necessary to do so. The PEP currently lists alternatives with caveats, and it's not immediately obvious from the PEP or the API documentation what the right alternative is for those caveats. As a condition of this PEP’s acceptance, we request that you fully document the recommended workarounds for these caveats. We do recognise that PyUnicode_EncodeDecimal is currently entirely undocumented. Documenting at this stage is probably not worth the effort, but perhaps it could be mentioned in a brief ‘porting’ section in the PEP instead. With the Python Steering Council's gratitude, Thomas. -- Thomas Wouters <thomas(a)python.org> Hi! I'm an email virus! Think twice before sending your email to help me spread!

2 1

Accepting PEP 597 (Add optional EncodingWarning)
by Thomas Wouters 16 Mar '21

16 Mar '21

Hi Inada, Thank you for submitting PEP 597 (Add optional EncodingWarning). The Steering Council is happy with the PEP, and hereby accepts it. The SC is of the opinion that we should move towards making UTF-8 the default encoding, and this PEP will make it easier to do so, and mitigate some of the confusion around the default encoding in the meantime. That being said, the SC would like to invite you and others with interest to work on a PEP for a long term plan to, in fact, change the default encoding to UTF-8. We don't want to make irrevocable decisions until we have a clear, viable plan with a good upgrade path and with community support, but we do believe we need to make that decision sooner rather than later. With thanks from the whole Python Steering Council, Thomas. -- Thomas Wouters <thomas(a)python.org> Hi! I'm an email virus! Think twice before sending your email to help me spread!

4 3

Rejecting PEP 637 (Support for indexing with keyword arguments)
by Thomas Wouters 15 Mar '21

15 Mar '21

Hi Stefano, Thank you for submitting PEP 637 (Support for indexing with keyword arguments). The Steering Council has reviewed the PEP and after careful consideration, we have decided to reject the PEP. There are a number of reasons for this, but fundamentally we do not believe the benefit is great enough to outweigh the cost of the new syntax. The benefits of the new syntax as outlined in the PEP are not particularly strong, and community support for the new syntax seems low. The new syntax doesn’t provide an obvious way to do something that is currently error-prone, and doesn’t open up new possibilities that were not possible before. While there are certainly cases that could use the new syntax, for many of them it’s not clear that it would be a win, or that third-party libraries would indeed use the syntax. The Steering Council isn’t really convinced by any of the suggested uses in the PEP. The strongest argument for the new syntax comes from the typing side of Python. The Steering Council is not particularly convinced it is of significant benefit to the static type checking language, but even if it were, at this point we’re reluctant to add general Python syntax that only (or mostly) benefits the static typing language. If the syntax would be of great benefit to static typing, it might be time to discuss letting go of the requirement that the typing language be a subset of Python -- but whether this feature is important enough to consider that is up to the typing community. The SC considers the cost of the new syntax significant. It’s not a natural fit, as shown by the corner cases discussed in the PEP. It’s difficult to teach, as indexing and function calls are not as interchangeable or equivalent as they may appear. Looking at more complex expressions with the new syntax, mentally parsing them is significantly harder than the equivalent without the new syntax, even if it requires more lines of code to do the same thing. In addition to all that, the SC is worried about the performance of indexing in CPython and in other Python implementations, considering it’s a very common operation, and about the suggested new __getitem__ protocol, particularly the confusing corner cases of indexing with keywords and zero or one positional items. These are not, however, the main reason we decided to reject the PEP. With our appreciation, For the whole Python Steering Council, Thomas. -- Thomas Wouters <thomas(a)python.org> Hi! I'm an email virus! Think twice before sending your email to help me spread!

1 0

Re: [Python-Dev] Re: [Release management] schedule for renaming the default branch
by Pablo Galindo Salgado 11 Mar '21

11 Mar '21

> I have above 200 feature branches in my local > repository. Will renaming > the master branch cause any problems? It should not be any problem at all. If you have some open PRs from some of those branches, they will be automatically retargeted to the new branch name in GitHub automatically. On Thu, 11 Mar 2021, 07:37 Serhiy Storchaka, <storchaka(a)gmail.com> wrote: > 10.03.21 16:06, Pablo Galindo Salgado пише: > > # What you need to do? > > > > You just need to update your local clone after the branch name changes. > > From the local clone of the repository on a computer, > > run the following commands to update the name of the default branch. > > > > $ git branch -m master main > > $ git fetch origin > > $ git branch -u origin/main main > > > > Apart from that, you should update any local script or command that uses > > the name "master" to use the name "main". > > I have above 200 feature branches in my local repository. Will renaming > the master branch cause any problems? > > _______________________________________________ > Python-Dev mailing list -- python-dev(a)python.org > To unsubscribe send an email to python-dev-leave(a)python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/G2LLBPJ… > Code of Conduct: http://python.org/psf/codeofconduct/ >

1 0

Re: [Python-Dev] Re: [Release management] schedule for renaming the default branch
by Victor Stinner 11 Mar '21

11 Mar '21

Hi Serhiy, On Thu, Mar 11, 2021 at 8:33 AM Serhiy Storchaka <storchaka(a)gmail.com> wrote: > I have above 200 feature branches in my local repository. Will renaming > the master branch cause any problems? I don't think that you need to do anything on your machine nor on your open PRs. When I use "git switch -c new_branch" command to create a new branch, the created branch doesn't "track" its parent branch by default. Example: $ git branch -vv (...) * gilstate_init a6959b8971 bpo-43311: Create GIL autoTSSkey ealier master 9a9c11ad41 [upstream/master] bpo-43287: Use PEP 590 vectorcall to speed up filter() (GH-24611) My "gilstate_init" local branch doesn't track any branch, whereas my local "master" branch tracks upstream/master (my upstream remote is git@github.com:python/cpython.git). Usually, when I want to easily see the differences between a local branch and my local master branch (to use my "git out" alias), I type "git branch --set-upstream-to=master": $ git switch gilstate_init $ git branch --set-upstream-to=master $ git out a6959b8971 bpo-43311: Create GIL autoTSSkey ealier where my "git out" alias is the command: $ git log '@{upstream}..' --pretty='format:%Cred%h%Creset %s' --color --reverse You can check that gilstate_init now tracks my local master branch: $ git branch -vv (...) gilstate_init a6959b8971 [master: ahead 1] bpo-43311: Create GIL autoTSSkey ealier master 9a9c11ad41 [upstream/master] bpo-43287: Use PEP 590 vectorcall to speed up filter() (GH-24611) Use "git switch -c new_branch --track master" to create a new branch based on master which tracks the master branch. Maybe I should track upstream/master rather than my local master branch, but when I fetch the upstream remote, I always update my local master branch, so in my case, it's the same in pratice :-) And "master" is shorter to type than "upstream/master". Victor -- Night gathers, and now my watch begins. It shall not end until my death.

1 0