python / steering-council Goto Github PK

View Code? Open in Web Editor NEW

154.0 79.0 23.0 151 KB

Communications from the Steering Council

Makefile 100.00%

python cpython governance

steering-council's Introduction

steering-council

This repo contains activity updates, process, and planning information for the Python Steering Council.

Office Hours

The Steering Council has office hours for anyone in the community that wants to discuss something with the Steering Council. Office hours are bookable half-hour video calls at the start of our regular weekly meeting. Currently it’s 30 minutes on Wednesday, 17:30 GMT (check your timezone here).

These meetings can be used by Core Devs, PEP authors and anyone else contributing to Python to discuss things they want to discuss with the Steering Council, when email or a GitHub ticket is for whatever reason not as desirable.

Scheduling is done through Google Calendar. When booking a slot, please make sure to do so at least 3 days in advance, and if possible include the topic in the appointment so we can be prepared. For longer chats, different schedules (we realise the current time isn’t always good for everyone), or pressing matters, contact us directly. We can always arrange something else.

Updates

These updates provide high level information about the Steering Council's activities. Subscribe to updates in your feedreader via the Atom feed for repository commits.

Process

These informational documents are collected here to aid the present and future Steering Council members.

Reference

steering-council's People

Contributors

Stargazers

Watchers

steering-council's Issues

PEP 587 "Python Initialization Configuration" is ready for pronouncement

Hi,

First of all, Brett Cannon selected Thomas Wouters @Yhg1s as the BDFL-delegate for my PEP 587. But I'm opening an issue for the Steering Committee anyway, because I'm out of time: next week, I will be off between May 30 and June 2, whereas the deadline for Python 3.8 feature freeze is at May 31 (2019-05-31).

In discussions, I saw Nick Coghlan, Brett Cannon and Barry Warsaw quite happy with the overall design. So I don't expect too much controverse :-) Hopefully, every tiny detail has been discussed to death on python-dev :-)

My PEP 587 is at the version 4. I got more feedback and so I am working on a 5th version:
https://github.com/vstinner/peps/pull/1/files

The 5th version is basically ready to be merged. But. I would prefer to not have a 6th version, mostly because I don't have time anymore :-) So I would prefer a review before merging it and I hope that the 5th version can be approved directly!

The overall design is the PEP 432 which is discussed since the end of 2012. The design and rhe mplementation of my PEP 587 is being discussed since July 2018 (see the Discussions section of my PEP). Users had plenty of time to provide feedback, and thanks to that, I was able to mature my API a lot very quickly!

I read again all previous discussions related to this PEP to ensure that all concerns are now taken in account. I was surprised by the high number of issues which are solved by my PEP. I'm talking about issues listed by users in discussions, but also the "Python Issues" section of my PEP.

Points which are not not addressed by my PEP:

By default, the path configuration is still automatically computed by Modules/getpath.c and PC/getpathp.c which are implemented in C. The configuration files are still used by default to compute the path configuration. This part is underspecified but I chose to not address it with my PEP, mostly because I didn't have enough time to work on this topic. But my PEP allows to completely override the path configuration and omits this function computing it.
It is not possible to modify PyConfig between Core and Main configuration phases in Python. It was a request of Steve Dower to easily reimplement the function computing path configuration in Python. Technically, it would take me less than one hour to add 2 functions to read and write the configuration. But I'm just too busy to experiment this, update the PEP, etc.

I tried hard to not expose the multi-phase initialization ("Core" and "Main" phases), but I got too much pressure from users, and so I decided to put it finally in the 5th version of my PEP. This API comes with a very explicitly warning: the proposed API is both private and provisional. Extract of the PEP:

the API can be modified or even be removed anytime until a proper public API is design

I chose to put the API at part of the PEP since it's a common and popular request, but also because it will allow us to get real feedback from users.

The documentation of the PyConfig and the Path Configuration is a work-in-progress. I plan to complete it before Python 3.8 final in the actual implementation.

Even if the PEP is approved, I still expect minor changes in the default PyPreConfig and PyConfig configurations, mostly to adjust the implementation or fix bugs. This default configurations is hard to design, but at least it now has a complete and mature test suite (Lib/test/test_embed.py and Programs/_testembed.c)!

Reminder: the whole PEP 587 is already implemented in the master branch, the PEP is only about making the API public :-)

Note: I spent so much time on the implementation and in the design of the PEP over the two last years, I would be sad if the API miss Python 3.8 deadline :-( We already missed 3.7 deadline, but that was a good thing: the implementation was far from being ready :-) (and the API was non-existent!)

Submission for SC consideration: PEP 637 - Support for indexing with keyword arguments

This issue opens up for consideration PEP 637 - Support for indexing with keyword arguments, with sponsor Steven D'Aprano. The proposal is the result of concerted effort on python-ideas and various requests to add keyword arguments to indexing operations, and replaces the five years old PEP 472 proposal.

A side effect of the implementation of this PEP is the handling of tuple unpacking, which is of particular relevance for PEP 646 - Variadic Generics

A prototype, not reviewed but functional implementation is available at the address in Ref. 9 of the PEP.

The feature has been discussed on python-dev at the following thread

https://mail.python.org/archives/list/[email protected]/thread/E3AMOIB3GKYAGN6IVSLEEKVP4VUEC2V3/

The general feedback is in favour of the PEP proposal, with no major objections. A last minute addition was performed to clarify the narrative to teach the feature to a typical "new to python" course audience.

A reminder to please submit discussion topics to Python Language Summit

From the SC's February update, it seems like there is intent from the SC to submit a topic about the TOML module.

Since we still have not received any proposal yet from steering council members, thought I'd be proactive and remind you all to submit the topic before March 22 (7 days from today).

Info: https://us.pycon.org/2021/summits/language/

I'm also interested to hear about with the issue with Python and Debian distro issues. Would this be something that you all want to discuss at the summit as well? Do you want to invite folks from Debian to join?

PEP review request: PEP 570 -- Python Positional-Only Parameters

We have recently finished the latest touch to the document for PEP 570 and we wish for the steering council to review it. Here is the document:

https://www.python.org/dev/peps/pep-0570

Here are some questions:

Can we suggest a PEP-delegate? If that is possible, we would like Guido van Rossum to be the PEP-delegate.
Should we submit the PEP document to python-dev or open a discourse topic for it?

Requesting a formal statement from the SC on politics in commit messages

#31 has stated that the offending commit message (and I use those words deliberately) will not be edited. However, there is still the open question of what will be accepted in the future. If nothing is done or said, the SC is effectively declaring that this commit message is perfectly acceptable and similarly barbed messages will be fully welcomed.

I request a deliberate and formal statement from the SC on this matter. If the stance is "we deplore this message, but would more strongly deplore the consequences of editing git history", then that would at least make a clear statement for the future. On the other hand, if you do accept the tone of this message, please make that clear.

Commit messages are normally an internal detail, and most advice on how to write them is focused on clarity and readability, not on what's appropriate. But this one has gotten itself into a very public position.

.py gTLD

Python has grown to be quite a popular language. #2 by many counts, and still rising in popularity. A .py gTLD may allow for projects to have a unique presence on the internet. Imagine tensorflow.py, django.py, flask.py, numpy.py (or num.py), etc. all having their respective domains.

This could potentially also be open to developers that wish to register their moniker under the .py gTLD, which many may in order to market themselves.

I'm off on my own island over here, so please let me know if this is completely off-base or has been considered before.

Submission for SC consideration: PEP 626 "Precise line numbers for debugging and other tools."

Initial feedback was mostly positive, but Pablo Galindo, Gregory Smith and Steve Dower brought up the issue of out-of-process debuggers and profilers.
I have address their concerns. Pablo and Ben Frederickson (author of py-spy) are happy with it now.

Priorities within CPython development for CZI proposal?

TL;DR: what are a few priority areas for CPython development where one full-time person or a few part-time people, working for one year, could make a big difference? Let's decide by July 7th and apply for CZI money.

Chan Zuckerberg Initiative's Essential Open Source for Science grant is going to open their next funding cycle to applications soon -- June 16th to August 4th, per the request for applications.

The PSF can apply for $50k-$250k USD for a 1-year project. The PSF has successfully gotten one of these grants already: $200,000 to improve the user experience and debuggability of pip (more details), and we've been welcomed to apply again.

I think the PSF should consider proposing at least one project that improves CPython. In my experience, projects need at least a few weeks to put together a good application, sometimes a month. So I would love to use this issue to generate some ideas, and then, by July 7th, have a consensus, aided by the Steering Council, on what to pursue. Then the new Project Funding Working Group (currently being formed) can help with advising proposal-writers and helping them get Board and/or Ewa's approval, and help get the proposal submitted before August 4th.

I suggest a few criteria:

CPython maintainers want it: there's already consensus among CPython devs, and if a PEP is involved it's been accepted.
fairly well-scoped
fundable: would happen much faster if the PSF got funding to implement the work. (So, it has to be legal and physically possible.)
applicable to biomedical research: so, for example, performance and reproducibility work is probably more relevant here than work on security or improving Python's teachability in the classroom.

My three suggestions to kick off discussion are:

make a chunk of progress on the GILectomy
make a proper start on property-based testing for Python builtins and the standard library (per this year's Language Summit)
hire a full-time core workflow manager and coordinator for one year

(Budget estimate: If we ask for and get $250K, and the PSF takes 15% overhead, we get $212,500. If we assume that PSF hires contractors for this work at an hourly pay rate at USD$115-$200 per hour, that's enough for about 1000 to 1800 hours of work. CZI funds one-year projects, so, at that pay rate, this ends up being the range between one half-time person and one full-time person.)

SC Ruling on appropriate uses for commit messages

Please make a statement about commit messages and their content, so we all know what to expect.

This is in reference to the recent commit message detailing the PEP-8 removal of Strunk & White as a guide for writing comments because it supported White Supremacy and encouraged "whiteness".

If such messages are acceptable then a requirement to have supporting links embedded so others can verify the accuracy of such statements would, hopefully, go a long way in averting more threads like those that resulted in this instance.

Heads up -- PEP 646, Variadic Generics

There's a typing PEP for generic variadics coming up, PEP 646. This has been discussed thoroughly on the typing-sig, and I'm the sponsor. I think they're ready to submit to the SC, but there's an in-person meeting tomorrow I want to wait for first.

Right now I'm writing because PEP 646 has a pretty strong dependency on PEP 637 (indexing for keyword args) which is also under SC consideration (#47). I don't know about the SC's agenda, but in case you're discussing PEP 637 tomorrow, I'd like to bring up the additional use case of generic variadics for some of the syntax being proposed in PEP 637, in particular the use of x[*y] (including things like x[a, *y, z]).

Also -- since this is a typing PEP, I hope it's not required to also discuss it on python-dev before submitting to the SC's consideration?

Submission for SC consideration: PEP 632 - Deprecate distutils module

It's time :) (to formalise the informal deprecation of the last decade ;) )

https://www.python.org/dev/peps/pep-0632/

The discussion at https://discuss.python.org/t/pep-632-deprecate-distutils-module/5134 reads like a list of potential delegates, if nobody wants it for themselves.

For SC consideration: PEP 642, Explicit Patterns for Structured Pattern Matching

The version being submitted is the 3rd posted version.

Now that I've submitted it, I'll still make changes in response to SC feedback, and fix any notable flaws that come up in community review, but it won't see the kinds of major design changes that happened between v1/v2/v3

The PEP itself contains a list of major changes relative to PEP 634, so I won't repeat that here.

Instead I'll summarise the parts that I consider most important:

ensuring that all "binding to the right" operations use the as keyword. This drove changes to both mapping patterns and class patterns.
explicitly qualifying both name bindings and value constraints with as, ==, or is. This change is the one that makes it possible to make pattern matching available to users without having to resolve the thorny questions of what bare names and attribute references should do by default. It also opens up the possibility of potentially adding more value constraint options later (like in, is not, and !=) if those operations seem sufficiently compelling to be worth adding.
explicitly decoupling sequence pattern matching from iterable unpacking. The change to require qualification of name binding operations already breaks the alignment between the two, and that created an opportunity to simplify the grammar by only allowing square bracket based sequence patterns and eliminating both open sequence patterns and parenthesis based sequence patterns
changing class patterns to draw more of their syntactic inspiration from mapping patterns rather than from class instantiation
explicitly representing patterns in the AST, rather than treating patterns as pseudo-expressions all the way through to the code generation layer. Skipping this step makes the code fragile and hard to follow, as there isn't actually any point in the AST that accepts both expressions and patterns, but with pattern parsing reusing expression nodes, you can't tell from just looking at the AST which nodes expect subexpressions and which expect subpatterns. Even if PEP 634's surface syntax ends up being accepted over this PEP, the explicit AST change should still be made to the implementation before it is merged.

And quote the example match statement from the abstract:

port = DEFAULT_PORT
match expr:
    case [as host, as port]:
        pass
    case {"host" as host, "port" as port}:
        pass
    case {"host" as host}:
        pass
    case object{.host as host, .port as port}:
        pass
    case object{.host as host}:
        pass
    case str{} as addr:
        host, __, optional_port = addr.partition(":")
        if optional_port:
            port = optional_port
    case __ as m:
        raise TypeError(f"Unknown address format: {m!r:.200}")

port = int(port)

Submission for SC consideration: PEP 652 -- Maintaining the Stable ABI

This issue opens up for consideration PEP 652 -- Maintaining the Stable ABI.

This PEP has been discussed on Discourse and before that on capi-sig.

I understand that the SC's backlog is big this time of year. Just putting the PEP on y'all's radar :)

Docs WG Google docs seems to be editable by anyone?

I'm seemingly able to open the link to the Docs WG Google docs provided here
https://github.com/python/steering-council/blob/master/updates/2021-01-steering-council-update.md#january-11
in incognito mode and edit it.

I haven't done anything mean (I promise!) but I suggest changing the sharing policies in the docs in case someone else does...

CC @willingc

How to submit documents relating to a PEP for consideration by the SC?

Currently there is no way to submit comments or documentation relating to a particular PEP to the SC for consideration.
Posting to python-dev can easily degenerate into a shouting matching or worse.
I was subjected to personal abuse when making a purely technical objection to PEP 526.
Discussion relating to PEP 622 and PEP 634 is much better, but can still be quite wearing.

It also seems unreasonable to expect the SC to review in detail every email sent to python-dev, but a superficial analysis merely encourages more shouting, as 10 "me too" emails will drown any attempt as reasoned debate or formal analysis.

What is the best way to submit documents?

Submission for SC consideration: PEP 612 "Parameter Specification Variables"

PEP 612 has been discussed and considered at length on the typing-sig list, since its first posting on December 19, 2019. The latest version now includes the features and syntax changes requested by the community, and has a full reference implementation.

We now seek approval from the Steering Council, either directly or through the appointment of a PEP-Delegate.

We are more than happy to answer any questions, or make any changes to the PEP based on feedback from the SC.

cc @gvanrossum

PEP 554: request for BDFL-delegate

PEP 554 has mostly been in a holding pattern since the middle of last year (due to the governance transition). It has been ready for pronouncement pretty much that whole time and really hasn't changed since before that (other than typos, formatting, and minor clarifications). As noted in the PEP, the implementation is mostly complete.

At this point I'd like to get the process rolling again for pronouncement. From what I understand that means requesting a BDFL-delegate. (I do not have anyone to recommend.)

Submission for SC consideration: PEP 647 -- User-Defined Type Guards

Please consider PEP 647 for inclusion in Python 3.10.

The PEP has been discussed at length in the typing sig here and here and in the python-dev mailing list here.

Reference implementations have been created in both Mypy and Pyright.

Submission for SC consideration: PEP 624 Remove Py_UNICODE encoder APIs

This issue opens up for consideration PEP 624 - Remove Py_UNICODE encoder APIs.

This PEP has been discussed in python-dev. I believe all points in the discussion is summarized well in the PEP.

(Since target version is Python 3.11, feel free to defer consideration and prioritize other PEPs targeting Python 3.10.)

Submission for SC consideration: PEP 597 Add optional EncodingWarning

This issue opens up for consideration PEP 597 -- Add optional EncodingWarning.

This PEP has been discussed in discuss.python.org and python-dev. The latest thread is here:

https://mail.python.org/archives/list/[email protected]/thread/SFYUP2TWD5JZ5KDLVSTZ44GWKVY4YNCV/

Older threads for previous versions of the PEP (oldest first):

Submission for SC consideration: PEP 616: String methods to remove prefixes and suffixes

I'd like to request that PEP 616 be reviewed by the Steering Council.

Title: String methods to remove prefixes and suffixes

Abstract: This is a proposal to add two new methods, removeprefix() and removesuffix(), to the APIs of Python's various string objects. These methods would remove a prefix or suffix (respectively) from a string, if present, and would be added to Unicode str objects, binary bytes and bytearray objects, and collections.UserString.

Links:

Discussion on Python-Dev
- More discussions linked in PEP
GitHub PR
BPO Issue

Evaluate whether standard library docs should use positional-only notation throughout

A pervasive change is being proposed for the documentation. It has some value in communicating what were formerly considered implementation details and it has value in more precisely specifying the language. It also has the effect of making the docs less approachable, creating a mental hiccup every time some reads those docs. Mariatta frequently gives talks suggesting that the existing docs already suffer usability problems for end-users. This change would make the situation worse.

See the PR and tracker discussion

Unlike other proposals, we do have some user testing with this and I think we would be foolish to ignore it. At least twice a month, I give intermediate/advanced training to people already using Python professionally. The reaction to this syntax is almost universally negative. Nothing from other languages looks like this. The notation does add information but typically not the information that people are looking for when they look something up in the docs. It is more than a minor distraction -- it immediately stops a reader in their tracks to decipher what it means:

b2a_uu(data, /, *, backtick=False)
    Convert binary data to a line of ASCII characters, the return value is the
   converted line, including a newline char.

compress(data, /, level=-1)
   Compresses the bytes in *data*, returning a bytes object containing compressed data.

I agree that a person can be trained to make sense of this; however, I also think a person shouldn't have to have training to read help(). If they are using help(), they are already alone and are looking for help.

In the cases like list(iterable=(), /), pow(x, y, z=None, /), sum(iterable, start=0, /), I don't imagine that a single user will ever be helped by this. In this history of Python, no actual user has ever complained that len(obj) was inadequate and that they would have been better served by len(obj, /).

I thought this warranted attention by the Steering Council because this changes the face of Python in a somewhat sweeping manner.

For myself, now speaking as user of Python rather than on behalf of users, I would personally get no value out of any of proposed doc changes.

Any core developer interested in doing a video interview for the Moscow Python Conference?

The Moscow Python Conference 2020 conference is hoping to air some recorded interviews of prominent Pythonistas at their annual conference (happening March 27). If anyone is interested in being interviewed, let me know! Here are the questions they have prepared!

What is your favorite Python feature introduced within the last few years?
What is the main challenge for async Python programming?
What one feature from any other programming language is a good fit for Python?
What are the strongest and weakest points in the Python ecosystem nowadays?
What parts of Python do you like to work on in the near future?

request: review basic approach of proposed Python 2 EOL page

Steering Council: please look at the work-in-progress draft of the Python 2.x EOL page I'm developing python/pythondotorg#1500 .

Questions:

I am designing this page to be very concise (currently under 660 words) and easy to read (currently has a Flesch Reading Ease score of 76/100 and Flesch-Kincaid Grade Level of 5.6, meaning a sixth-grader could read it). Is this basic approach okay with you?
- Relatedly: In the initial display of this page, I'm going for broad accuracy over precision. For each generalization I can add a footnote with details and link to the specific claims, dates, citations, etc. Is that okay?
Is it okay to name specific vendors who are offering post-EOL commercial support? If you'd like, instead of naming vendors in this page, I could quickly set up and link to a wiki page where they could list themselves. I think this will help users.
Are there any major inaccuracies in what I have written?

I would appreciate a review by the end of the day Tuesday August 27th. Thank you.

Vote to promote Paul Ganssle as a core developer ended

The vote closed 12 hours ago:

Promote Paul Ganssle: 41 (95%)
Don’t promote Paul Ganssle: 2 (5%)
Total: 43 voters

Steering Committee: what's your call on this promotion?

https://discuss.python.org/t/vote-to-promote-paul-ganssle-as-a-core-developer/1826/8

cc @pablogsal

Submission for SC consideration: PEP 648 Extensible customizations of the interpreter at startup

After some feedback in discourse I want to submit PEP 648 for the SC consideration. I'm not a core dev, this PEP submission is sponsored by @pablogsal.

PEP: https://www.python.org/dev/peps/pep-0648/

Thanks!

Fix name mention in 2019-02-26 Steering Council Update

This line of the Feb. 26 update says:

Consider PEP 580 - Chris Jerdonek request (PENDING)

I believe this is supposed to say Jeroen Demeyer (not me).

Submission for SC consideration: PEP 644 -- Require OpenSSL 1.1.1 or newer

Please consider PEP 644 for Python 3.10.

The PEP has been discussed at https://discuss.python.org/t/pep-644-require-openssl-1-1-or-newer/5584 since October 2020. So far nobody has argued against the PEP.

The PEP has been cited in other places, e.g. Void Linux used it as an additional argument for their move back to OpenSSL in the recent announcement https://voidlinux.org/news/2021/02/OpenSSL.html .

Meetings/updates?

Hi! I just noticed that there haven't been any updates in this repository for several months; is there someplace else I should be looking for meeting outcomes and updates? Thank you!

Python 2 sunset preparation: docs.python.org deep links

The current handling of deep links on docs.python.org is covered by PEP 430:

unqualified deep links resolve to the Python 2.7 documentation
the canonical URL for up to date Python 3 documentation includes a /3/ segment in the path

That approach made sense when I wrote PEP 430, but that's almost 7 years ago now, and there's the potential to ask the PSF for assistance in the somewhat tedious task of implementing a more sophisticated solution for adoption as part of the Python 2 sunsetting process (and also easing a possible future transition to a python 4.0 release if we ever decide to make one of those rather than continuing with double-digit minor versions in the 3.x series).

I'm not planning to write that PEP myself, but some potential ideas that it could cover:

switching the canonical URL for the English Python documentation from "docs.python.org/3/" to "docs.python.org/en/" (in alignment with PEP 545)
setting the canonical URL even on old maintenance branches that are otherwise no longer receiving documentation updates (either by making one final commit to them, or by amending the HTML files directly on the documentation hosting server)
setting the canonical URL meta tag even in the Python 2.7 documentation to refer to the relevant "docs.python.org/en/" URL (but do the work to handle module renames and other moves correctly)
adding a banner to end of life versions that clearly indicates that the specified version is no longer receiving security updates, and potentially also linking to the latest version (see https://docs.djangoproject.com/en/1.10/ref/django-admin/ for an example of such a banner, albeit without a direct link to more recent documentation)

Time zone module: PEP or no PEP?

Greetings Steering Council,

Last year at the language summit, I proposed adding time zones to the standard library, and it seems that it was a mostly uncontroversial proposal. It has taken me a while to actually get things together, but I am almost at the stage that I will need some review for the public interface. I am hoping to get at least a pure Python version of this in before the feature freeze this year.

At last year's language summit, I suggested that I should write a PEP, mainly based on the fact that a PEP had already been proposed on this topic, PEP 431, and been rejected. However, reading through PEP 431 and PEP 495, I realized that both of these are really looking to make changes to the datetime type, whereas (now that PEP 495 is available), my new proposed module is self-contained and needs to make no changes to existing interfaces, so I am not sure if this needs a PEP or if I should just go through normal channels for review.

I can see a few possible reasons to go with a PEP:

To document the interface of the new module (though this can and will be covered in the Python documentation anyway).
I am proposing that the implementation would default to using the system time zones, and I plan to propose a few mechanisms for the search path:
- One or possibly a few runtime environment variables (e.g. PYTHON_TZPATH) that would affect where the module looks for time zones.
- A compile-time option specifying the default search path (to allow distros that know the path ahead of time to prune out the unnecessary options, or add missing options)
- A function in the module to modify it from Python
  Seems like several of those options might trigger a PEP.
I intend to add an opportunistic dependency on a PyPI-manage package, tzdata (which is to say that if you have tzdata installed and your system is missing a given time zone or has no time zones installed, it will load from the package).

The main downside of writing a PEP that I see (beyond the obvious "SC time is valuable and I shouldn't hijack it to get a code review") would be that PEPs are frozen after acceptance and eventually the "documentation by PEP" may grow stagnant.

Please let me know how you'd like me to proceed.

Submission for SC consideration: PEP 654 -- Exception Groups and except*

Please consider PEP 654 for inclusion in Python 3.10.

The PEP has been discussed at length on python-dev and the discussion has come to a natural end (perhaps a steady state :-). Irit has a fully working implementation (though it needs some cleanup) and it would be ready to land in time before 3.10b1 (May 3rd).

/CC: @1st1, @iritkatriel

Submission for SC consideration: PEP 646 -- Variadic Generics

Please consider PEP 646 for inclusion in Python 3.10. This is primarily of interest to users of static type checkers, especially projects looking to implement shape checking for tensors (an important concept in the machine learning world, where Python's dominance is seeing competition from e.g. Swift for Tensorflow).

There are some small additions to Python's syntax in the proposal, namely the * operator in subscripts and for *args in function definitions. These are essentially just new uses of the existing "sequence unpacking" concept.

The PEP has been discussed at length in the typing sig, and the python-dev mailing list has been notified.

There are reference implementations of the checking part in Pyright and Pyre. There is a nascent patch for the syntactic changes to CPython where.

/CC: @mrahtz

https://www.python.org/dev/peps/pep-0646/

Temporarily ban and formerly reprimand for users that violated Brett's ceasefire request

In his message https://mail.python.org/archives/list/[email protected]/thread/B2CFXHM2ND3KOYGLTBOYK4H2VMGRZT7J/ Brett asked users to refrain from replying to the PEP 8 discussion thread for 24 hours. His request has been violated by several users, PSF members, and Python core developers. I like to request swift and strong action from the steering council on the violation of Brett's request and propose following actions:

Temporarily ban user from python-dev for one month
After one month users may appeal and request a removal of ban with a written apology.
Give a formal warnings for all core developers that have violated the request.

Personally I would even go so far and issue "strike one" for violators. (strike three = your are out)

In my humble opinion a swift and strong reaction is required to salvage what is left of python-dev. Some core developers have already been left and unsubscribed from python-dev mailing list. I will unsubscribe unless the situation improves and violators are disciplined. I'm holding my fellow core developers and PSF members to an even higher standard. Core developers and PSF members should lead by example and strive for excellence.

Submission for SC consideration: PEP 615 "Support for IANA Time Zones in the Standard Library"

I would like to submit PEP 615, adding a new zoneinfo module to the standard library, for consideration to the Steering Council.

I have advertised the PEP on the datetime-SIG and python-dev mailing lists, and solicited outside feedback from the IANA tz mailing list. The discussion on the discourse has settled down, and it seems that all open issues are resolved.

A reference implementation for the zoneinfo module and the first-party PyPI package tzdata are available to use.

Would it be possible for the Steering Council to consider this proposal or assign a BDFL-delgate?

I realize that I haven't left much time for this, but I was hoping (for reasons of whimsy) to get this accepted on Sunday, April 5th either between 02:00-04:00 UTC or between 13:00 and 17:30 UTC, since those times represent ambiguous datetimes somewhere on earth (mostly in Australia). There is one other opportunity for this, which is that on Sunday April 19th, the hours between 01:00 and 03:00 UTC are ambiguous in Western Sahara. I believe these are the last ambiguous datetimes before the feature freeze for Python 3.9 -- feel free to ignore this as it is not as important as getting the implementation right, or respecting the steering council's time and other priorities, but I thought it might be fun.

Relevant links:

PEP 615: https://www.python.org/dev/peps/pep-0615/
Discussion: https://discuss.python.org/t/pep-615-support-for-the-iana-time-zone-database-in-the-standard-library/3468
Reference implementation: https://github.com/pganssle/zoneinfo
Reference implementation for tzdata: https://github.com/pganssle/tzdata

For SC consideration: PEP 634 and PEP 635, Pattern Matching

This replaces #33.

The implementation is shaping up nicely (Pablo has volunteered to review) and we're hoping to land this in 3.10 alpha 3, slated for December 7.

I just sent an announcement to python-dev.

As discussed, we abandoned the old PEP 622 and broke it up into three parts:

PEP 634: Specification
PEP 635: Motivation and Rationale
PEP 636: Tutorial

Of these, PEP 636 is informational, and at this point there's probably nothing new for the SC members. The other two are meant to be read side by side, where PEP 634 gives the pure specification and PEP 635 gives the rationale for each design decision, including discussion of alternatives considered. We're really only asking for approval of the specification (PEP 634).

A TL;DR of substantial changes (I hope I didn't miss anything):

We changed walrus patterns ('v := p') to AS patterns ('p as v').
We changed the method of comparison for literals None, False, True to use 'is' instead of '=='.
SyntaxError if an irrefutable case[1] is followed by another case block.
SyntaxError if an irrefutable pattern[1] occurs on the left of '|', e.g. 'x | [x]'.
We dropped the @sealed decorator and everything aimed at static type checkers.

[1] An irrefutable pattern is one that never fails, notably a wildcard or a capture. An irrefutable case has an irrefutable pattern at the top and no guard. Irrefutability is defined recursively, since an '|' with an irrefutable pattern on either side is itself irrefutable, and so is an AS pattern with an irrefutable pattern before 'as'.

The following issues were specifically discussed with the SC previously:

Concerns about side effects and undefined behavior. There's now some specific language about this in a few places (giving the compiler freedom to optimize), and a section "Side Effects and Undefined Behavior".
Footgun if case NAME: is followed by another case. This is now a SyntaxError.
Adding an 'else' clause. We decided not to add this; motivation in PEP 635.
Alternative 'OR' symbol. Not changed; see PEP 635.
Alternative wildcard symbol. Not changed, but Thomas wrote PEP 640 which proposes '?' as a general assignment target. PEP 635 has some language against that idea.
Alternative indentation schemes. We decided to stick with the original proposal; see PEP 635.
Marking all capture variables with a sigil. We all agreed this was a bad idea; see PEP 635.

Submission for SC consideration: PEP 649 -- Deferred Evaluation Of Annotations Using Descriptors

I apologize for the lateness of the submission--but here it is, PEP 649.

I'll keep an eye on this issue in case I can answer any questions for the committee here.

Thank you for your time.

PEP 578: Request for delegate

I'd like to request a delegate to review and pronounce on PEP 578. I don't have anyone in particular in mind.

https://github.com/python/peps/blob/master/pep-0578.rst
https://www.python.org/dev/peps/pep-0578/ (couple minor PRs still in flight)

My implementation against master is at python/cpython#12613

Submission for SC consideration: PEP 609 -- PyPA Governance

On behalf of @pradyunsg and @brainwane, and myself, I'd like to submit PEP 609 -- PyPA Governance for consideration to the Steering Council.

PEP 609: Overview for Steering Council

Why does the PyPA want a formal governance model?

The PyPA started in 2011 as a loose confederation of developers, trying to create an alternative to the standard utilities. At that time, informal personal relationships were sufficient to help developers make decisions. Now that the PyPA maintains the canonical package repository and the official toolchain for uploading to it, downloading from it, as well as for creating, distributing, and installing Python packages. We need more systematic ways to make and enforce decisions. Examples:

A new project asks for membership. Should we admit it, thus granting an imprimatur?
An architectural decision will affect several PyPA projects. Whose approval is necessary? When have we reached consensus? When is the deadline to make that decision?
Someone wants the PyPA to run differently. Who decides what is mandatory?
There’s a new internship program that will help us get new contributors, but participating will increase our support load in the short run. Should we participate?
A member of several PyPA projects is disruptive. Who has the power to remove their membership, and what is the procedure they should follow?

Right now, the answers to all of those questions are basically “There’s no real answer -- ask around, talk about what you want in the mailing lists and on Discourse, and eventually maybe a consensus will form” (with no certainty on how long that will take). This discourages new contributors, corporate participation, and large architectural projects, and slows the overall decision-making process.

Why does the PyPA currently have a BDFRN?

PyPA members in 2018 nominated Dustin Ingram as the Benevolent Dictator For Right Now (BDFRN), to document existing practices and bootstrap the PyPA into its first formal governance system. That culminated in creating this PEP. Acceptance of this PEP will dissolve the role of BDFRN.

What are the alternative models considered and their trade-offs?

Originally, the BDFRN proposed “The Lightweight Model”, a consensus-based governance using an RFC process, replacing the existing PEP process.

This model had the following goals:

Provide support for existing projects under the PyPA
Foster the creation and acceptance of standards for PyPA projects
Guide decisions which affect multiple PyPA projects
Accept new projects into the PyPA
Enforce adherence to the CoC uniformly across all projects

PyPA members felt that adding a separate RFC process to replace PEPs was redundant, and that instead the existing PEP process could be adjusted to better suit the PyPA’s use of it.

Next, this proposal was updated to what was called “The Status-Quo Model”: same goals as above, but eliminating the proposed RFC process and instead using the existing PEP mechanisms. This model also adds voting for governance-related decisions based on PEP 13.

Finally, the model was updated to enforce the PSF Code of Conduct rather than the PyPA Code of Conduct after it was discussed.

This model is the final proposed governance model.

How would PyPA’s use of the PEP process be affected?

The PEP process is designed for and coupled to core development (e.g., a Core Dev needs to sponsor). This is increasingly incongruous as packaging development is fairly isolated from core development. Most PEPs about packaging do not concern core development, and vice versa.

Paul Ganssle wrote:

I think at the very least there needs to be a process by which PyPA members can be empowered to make these proposals without a sponsor: I am ambivalent as to whether that is automatic upon joining any PyPA project or whether there’s a slightly higher bar - but it cannot be as high as “is a core dev of CPython”.

Originally, the governance proposal outlined a new RFC process, similar to PEPs, but explicitly for Packaging standards, giving the PyPA more flexibility with who can propose standards and who can approve standards.

During discussion, it was expressed that a new RFC process would be mostly duplicative of the existing PEP process. As a result, we decided to ask for changes to the PEP process instead, to better suit the PyPA’s needs.

What changes would better accommodate the PyPA’s usage of the PEP process?

We have two main changes to suggest:

Namespacing for PyPA-related PEPs. Make it easier for us to find, list, and refer to PEPs that are primarily of concern to Python packaging developers.
Expand sponsorship eligibility. As mentioned above, the PyPA would like more flexibility regarding who can propose standards, The PyPA would determine a list of people allowed to sponsor PyPA-related PEPs. PEP 1 or the Standing Delegations list would need to be revised accordingly.

Why is the PyPA bringing this to the Steering Council for a decision?

The PyPA does not have authority to approve these changes. We’ve arrived at this model after years of discussion, and would like either to move forward with it, or an alternative way to achieve the goals listed above. This is not the end of the discussion; after the Steering Council decides on this PEP, ideally the PyPA and the Steering Council will continue to discuss and refine the scope of the PEP process, how and when it applies to packaging-specific standards and architecture decisions, and how we all might adapt governance processes further.

References:

“The Lightweight Model”: https://gist.github.com/di/c785bf9a04f6c5f52d7baf332204f05a
“Proposal: "Lightweight" governance model for PyPA”: https://mail.python.org/archives/list/[email protected]/thread/JNALHKBLRTSRRTKQV2KL72CJMV6DXUNX/
“Closing the loop on PyPA Governance / BDFRN”: https://discuss.python.org/t/closing-the-loop-on-pypa-governance-bdfrn/1776/
“PyPA Governance - A “Status-Quo” Model”: https://discuss.python.org/t/pypa-governance-a-status-quo-model/2221
“Should PyPA opt out of the PEP process?”: https://discuss.python.org/t/should-pypa-opt-out-of-the-pep-process/2645
“Move to the PSF Code of Conduct?”: https://discuss.python.org/t/move-to-the-psf-code-of-conduct/3876

Submission for SC consideration: PEP 467 - Minor improvements to binary sequences

I am submitting PEP 467 for review by the SC in hopes that it can make it in to 3.10. I do have an email out to @ncoghlan to see if he has any objections to the last two minor changes I made.

Most of the code and tests are already written.

Thank you for your time!

PEP 618: Self-Nomination for BDFL-Delegate

@gvanrossum has agreed to act as BDFL(-Delegate?) for PEP 618.

While PEP 1 states that such self-nominations are accepted by default and can be vetoed by the SC, it's otherwise quite vague. Beyond the PEP header, is there any requirement to communicate the decision to the SC or others? If so, how?

Should we delegate typing PEPs to a separate body?

Once the beta 1 is on its way, maybe the SC would like to lighten its load by permanently delegating PEPs related to typing to another body, similar to the way it's done for packaging PEPs.

PEPs proposing new syntax would still have to be approved by the SC, but PEPs that just propose a new "special form" to be added to the typing module would just have to be approved by a newly formed body in which representatives of the major static type checkers are present (I think that's PyCharm, mypy, pytype, pyre, and pyright).

Thoughts?

PEP 617: New PEG parser for CPython -- please review ASAP

I, @pablogsal and @lysnikolaou have been working on a new parser for CPython based on PEG technology. We are presenting our work at the online language summit (Wd 4/15, 9:45am Pacific time) and we are hoping to land the code in time to make it to 3.9.0 alpha 6, which is planned to go out on Wednesday, April 22, i.e. in 9 days. Please read PEP 617 for more details.

We are currently down in the engineering work of getting the last few details matching between the old and the new parser (e.g. certain error messages representing edge cases), and I am certain that we will be able to merge the code in time for alpha 6, provided we have SC approval (or at least non-opposition) and provided the general response at the online language summit is positive enough. (And we get review from a core dev other than the PEP authors.)

Submission for SC consideration: PEP 585 "Type Hinting Generics In Standard Collections"

I'd like to ask the Steering Council for a decision whether this PEP should be accepted and implemented for Python 3.9.

I wrote this PEP last year and since then it got through several significant editing rounds. We have also done several discussion rounds, and there's a prototype implementation by @gvanrossum and @ethanhs.

PEP text

https://www.python.org/dev/peps/pep-0585/

typing-sig discussion

python-dev discussion

https://mail.python.org/archives/list/[email protected]/thread/VYUM3GLXCDFKU6URHN5IPT2UTVESEO4B/#VYUM3GLXCDFKU6URHN5IPT2UTVESEO4B

prototype implementation

Submission for SC consideration: PEP 637 - Support for indexing with keyword arguments

A side effect of the implementation of this PEP is the handling of tuple unpacking, which is of particular relevance for PEP 646 - Variadic Generics

A prototype, not reviewed but functional implementation is available at the address in Ref. 9 of the PEP.

Clarify delegations to PyPA allow PyPA members to also be PEP sponsors

See #29

/cc @brainwane

PEP 394: Change review request

I submitted a PR that substantially modifies PEP 394: python/peps#989

I'm not sure about procedures for modification of existing PEPs. It would make sense that they need to be approved by the SC or BDFL-Delegate.
Is that the case? If so, I'd like to ask for a pronouncement/delegate.

Repositories under the "python" organization on GitHub

On Thursday, May 2nd, I moved the Black project from ambv/black on GitHub to under the "python" organization. Nick Coghlan raised concern that there is a missing standard for what kinds of projects fit under "python" and a missing process for moving an existing project to it. It's also as of yet unclear what kind of governance under the PSF-provided "python" organization on GitHub should the Steering Council hold. I'm creating this issue to track those questions.

python/black

Since moving Black triggered this issue, I'd like to take a moment to explain how we arrived at it.

What is Black?

Black is an opinionated code formatter implementing a subset of PEP 8. Over the past 14 months of its existence, it took the Python world by storm. It's got three times the stars on GitHub as autopep8, and surpassed YAPF in monthly downloads from PyPI.

It's now used by notable open-source projects like pytest, tox, Pyramid, Django Channels, Hypothesis, attrs, Poetry, PyPA applications (Warehouse, Pipenv, virtualenv), Pallets libraries (Werkzeug, itsdangerous, MarkupSafe), and many others. Popular editors for Python like Visual Studio Code and Mu ship with Black formatting by default. Mercurial introduced support for tool-aware merges with Black in mind. In fact, there is a DEP to format the entirety of Django with Black. Twisted and Flask are interested in adopting Black during the PyCon sprints.

What is the case for Black living under "python"?

Black is already used in the development of CPython. The new pgen created by Pablo is formatted with Black. Maintainers of dataclasses and asyncio in the standard library are interested in having their libraries auto-formatted. To start off, I'm going to set up the required infrastructure for this during PyCon sprints with configparser being the first auto-formatted module in the standard library.
I felt that keeping the tool under a personal account on GitHub was wrong. First, it's a risk in case if I suddenly could not continue development. It also makes other contributors feel less ownership over the project. Finally, it creates unproportional focus on the creator versus the project.
The mission of the tool is to accelerate development with Python by solving bikeshedding over formatting and creating consistent results with minimal diffs. One of the successful innovations of the Go programming language was the introduction of "gofmt", a formatting tool with a similar goal that was easy to find and ready to use out of the box. Having an established tool like this for Python was a wish of many programmers, myself included.
There is precedent under "python" in the form of Mypy which is a tool with a separate set of core developers, advertised as optional, and not treated as an official type checker.

Did you ask?

Yes, I talked with many core developers in person during the sprint at Microsoft. I asked the room at the Language Summit, with all Steering Council members in attendance. In both cases, the reaction was rather indifferent and no strong objections were raised.

Additionally, core developers are authorized to create (and thus move) repositories within the "python" organization on GitHub.

Submission for SC consideration: PEP 622 "Structural Pattern Matching"

PEP 622 has gone through extensive review -- we posted a first draft on June 23rd and a second, greatly improved one, on July 8th (a week ago today). While the first draft spawned intense pushback, the second draft has been mostly received positively, with the exception of Mark Shannon -- but we feel Mark's criticism has been adequately responded to.

We now seek approval from the Steering Council, either directly or through the appointment of a PEP-Delegate. We are happy to answer any questions about the PEP -- we understand it's a long one and some fine points may be somewhat buried. We also understand the SC has a backlog of decisions and may not be able to give us a decision in the next few weeks, but we are hoping for a decision in time for the first 3.10 alpha release.

For SC members who haven't followed the debate, probably the best way to get into it is to start reading my cover letter for the 2nd version, and then just read the PEP itself (it starts with an overview that should be easy to follow).

We are of course also happy to make changes to the PEP based on feedback from the SC. In particular there are a couple of somewhat controversial issues left:

The indentation scheme. We think that the current proposal has the least surprises, but we understand not everybody likes it.
Whether to add an else: clause. We favor to use case _: here, and there is considerable debate about the indentation of the else clause if it were to be added.
How to indicate the difference between "load" (for value patterns) and "store" (for capture patterns). We currently favor using an unqualified name for stores[1] and making qualified (i.e., dotted) names for loads, since this appears to us to be the cleanest scheme of all, and in most cases stores will greatly outnumber (unqualified name) loads. But some folks seem to be keen on having some notation to load an unqualified name. Many competing proposals have been made, but none that look very satisfying. Fortunately it's easy to add one of these in the future if we find that the need is strong (which we don't anticipate).
How to spell wildcards. The PEP authors strongly believe that _ is the right choice here. A few readers have objected to this (because it can't work exactly the way _ works in assignment targets) and proposed other notations. Most recently Larry Hastings' proposed using ?. In his final message on the topic he seems to at least agree that it's not easy to make everyone happy and said he wouldn't pursue it further.

[1] This follows the lead of the walrus operator (PEP 572). We also follow its lead in not establishing new scopes for capture variables.

Submission for SC consideration: PEP 651 Robust Stack Overflow Handling

The, admittedly limited, feedback on Python-dev was positive.

@pablogsal expressed some concern about how this would impact out-of-process debuggers and profilers, as they would have to cope with Python-frames being many-to-one to C-frames instead of the one-to-one, as they are used to.
Pablo seemed to think that if Tools/gdb/libpython.py can be updated to work with the new frame layout, then it is reasonable to assume that other tools can do so.