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
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>
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
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)
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!
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!
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!
> 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/
>
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.