Collecting questions for a Steering Council Q&A

As part of PyCon US 2020, we are planning to record a Q&A with the Steering Council. We are using this topic to solicit questions from the community. We plan to leave this open for about a week.

Thanks for all of those who leave a question (which adhere to the PSF Code of Conduct :wink:)!

P.S. Do make sure to check out the various talks that have been posted for the conference so far! And thanks in advance to Ewa, Emily, and the whole PyCon US 2020 staff for making this Q&A possible.


The main question I have, I hope not too abrupt is: what are you doing? :wink:

I mean this literally and without aggressivity, but since - unless I missed something - there haven’t been much news of the SC’s activity, it feels like not much is happening. Very likely that impression is false, so it would be good to be a bit more informed. Including any WIP stuff where the community may give input or benefit from progress details.

Also, it would be good to have a writeup, which is much more comfortable to digest for some people (like me :wink: ) than a video session. Not necessarily the whole transcription (which may be workforce-consuming), but at least the important points.


What can the steering committee do to make sure Python continues to serve the needs of all its users, and not just those who have backgrounds similar to our excellent core developers?

A bit of history

Visual Basic 1.0 was a wonderful tool for Opportunistic Programming, and Python still is. However, starting with VB 4.0, Microsoft tried to cater to professional developers, and they lost their original, enthusiastic VB following which included people from all walks of life who just wanted an easy to use programming language. Visual Basic is now too complicated for non-professionals, while many professionals still find it inadequate.

Python’s audiences

Python’s #1 strength is the diversity of its users: besides computer scientists and software engineers, we have system administrators, researchers from every field, financial analysts, and kids learning to program—to name a few different communities in a spectrum from professional developers to opportunistic programmers who value ease of use over efficiency and maintainability.

"Pro" feautures

As a long time user and teacher of Python, lately I wonder if we are not making it less accessible to people that are not professional developers. Two examples of features that favor the needs of the “pros”, while adding complexity and little value to “non-pros”: assignment expressions and type hints. We know how much effort went into arguing the former, and there are 17 PEPs related to typing—no other part of the language has so many. I understand that both features are optional, but they reflect a certain focus. Also, both require significant technical background to make sense, so they may be obstacles to people learning Python as a first language (or as a first “typed” language).


Some Background
I am a new user to Python. I came to Python when I needed to analyse some data and Excel could not do it well/ as flexibly.

Maybe it is not the job of the steering committee but what is the work being done by the core(in the sense of as a push rather than a pull) of Python to Market Python to different use cases. The thing is there are so many languages out there with just as active a community as Python. There may be need like Intel did, where appropriate, to push Python as the language for a specific new or established field in a continuing basis. In my case I found many tools for data processing - and suspect there are other small niches where Python could be a dominant tool also.

Thank You

What is the future of asyncio library?
I saw some big api improvements in september before 3.8 in dev docs, but suddenly they were reverted totally. AFAIR it was done to take a pause before decision to what to do with low-level (transport, protocol), high-level (streams) api’s comes.

Is there any news about restructuring standard library?
I heard of discussions about stripping standard library to remove some modules and/or host them on pypi as libraries. What is the current state of this?

Why packaging improvements are so slow?
I mean, packaging still is a mess, since building native extension via distutils is hard and bad documented. Maybe this question is misaddressed and should be asked to PyPa, but I’m not sure.

1 Like


Thanks for spending the time you do on the steering council, especially since you are already investing yourself in the community somewhere else.

I was wondering:

1 - Is there some entity in charge of the global vision for the Python language right now?

The BDFL used to implicitly fill this need, but and correct me if I’m wrong, it does not seem to be the role of the steering council.

I am worried that agglomerating ideas from all the core devs, be it under the supervision of the SC, may not be enough to keep the Python experience to something coherent and practical on the long run. Or to maintain balance between modernity and compatibility.

If I’m wrong, then what is currently the vision? If I’m on to something, do you think it would be in our interest to setup a mechanism to build a vision?

2 - Can you give us an update about the packaging debate?

Packaging is still a hot topic after all those years. I remember a recent long thread on twitter with several members of the community, of Pypa, and Peter Wang from anaconda, that ended up with a lot of strong points like:

  • python is currently used as a sdk and a runtime

  • packaging pure python libs is easy, but end user applications hard, however people confuse both use cases

  • python import system was as the root of this situation

This is a very dear topic to many, so what can you tell us about it?

3 - Do you believe we should reopen debates on features that never made it to python or consider them permanently off scope?

Some ideas such as exception-catching expressions, pattern matching, null coalescence, dict unpacking, etc. have been heavily discussed on python-ideas, but never transformed into reality. Some of them because they weren’t championed, many because they were rejected.

However, the walrus operator prove that things that would have been vetoed by Guido van Rossum 10 years ago may be considered ok now. On the other hand, the ex-BDFL has given us the clean language with have today by virtue of refusing a lot of things.

What is your take on this?


Are you going to do anything about the dev team not being able to handle the stream of incoming bug reports and PRs?

E.g.: sign up new team members, or make existing members more productive?

AFAICS from discussions at python-dev, the mail roadblocks limiting the productivity are:

  • Possibility of post-merge breaks, the dev team rather than contributors being forced to handle them, and the buildbot infrastructure that they happen at being invisible from BPO and PR UI.
  • Unclear requirements to code in PRs, forcing devs to do lots of guesswork about what is acceptable.
  • No prominently visible user-level statistics on this activity, including code reviews and closures, making this work “invisible” and thus feel sisyphean and unappreciated. Which also limits external involvement in it.

What are the top problems facing the Python language today?

These could be spread across user challenges, core development, governance, community, computational [ hopefully not the GIL :wink: ]… and so on.
I’m asking this to understand the background of your mandate and to know what the council is actively tackling.

  1. Are you planning to add switch statements anytime soon?

Coming from a C# / Java background, one thing I really miss is the switch statement. It is really useful when you have a large amount of possible outcomes based upon the value of a variable or calculation.

I realize that the necessary double-indentation is frowned upon for reasons of unreadability, however I would argue that sometimes it is more readable. For example, consider this really hard-to-follow string of if statements:

foobar = 34
asdf = "333"

if random_variable + another_random_variable == 33:
    if (x := (foobar + int(asdf) == 33223)):
    elif x == 3231414:
    elif x == 3131313:
    elif x == 0101010:
    elif x == 3222:
    elif x == 3333211:

This by itself can be confusing read; when it is inside another statement(s) it can be a nightmare. switch statements, on the other hand, are much easier to read in these scenarios; as much as people dislike it, the double-indent makes it quite a bit easier to figure out which statement it is in. For example, here is the same if statement rewrote using a switch statement:

foobar = 34
asdf = "333"

if random_variable + another_random_variable == 33:
    switch foobar + int(asdf):
        case 33223:
            break # I suggest making this optional.
        case x == 3231414:
        case x == 3131313:
        case x == 0101010:
        case 3222:
        case 3333211:

This is much more readable; the scope is (in my opinion) a lot more obvious.

Specific feature proposals seem to be a bit out of the scope of questions directed at the SC.

Instead, I would first recommend reading up on existing PEPs (275 and 3103) and searching the mailing list archives (python-ideas and python-dev) for prior discussions around the switch statement. Then, if you have additional arguments or counter-arguments to those made in prior discussions, it would be best presented in the python-ideas mailing list and/or here on discuss in the #ideas topic.

FWIW I am working with a few folks on a design for a match statement based on a summary by Tobias Kohn posted in Sept. 2018 to python-ideas.


High-priority projects: If you were compiling a list of strategically important Python areas and projects, similar to the Free Software Foundation’s list of High Priority Projects, what are 2 things you might put on it?

FSF’s list “draws attention to a relatively small number of projects of great strategic importance … The list helps guide volunteers, supporters, and companies to projects where their skills and resources can be utilized, whether they be in coding, graphic design, writing, financial contributions, or activism.” Their criteria seek out things that would, for instance, break logjams, and make adoption and participation more compelling for many more people.

Priorities for hiring staff: In the past year you have probably developed a stronger understanding of what staff support the Steering Countil and Python’s development need, and how much PSF staff time is dedicated to this. If the PSF could afford to hire a few more staffers to support core Python, what would you prioritize in that hiring? Maybe code review, website upkeep, community management, logistics/administration, user experience research/design, product management, systems administration, finances/accounting, hardware evaluation, marketing, project management, technical writing (especially given Carol Willing’s talk on documentation improvements at the Language Summit), or grant proposal writing?


What’s the plan for the following?

  • Python in the browser
  • Python on mobile
  • multi-core Python ()
  • C-API evolution
  • embed-ability
  • performance improvement
  • collaboration with corporate teams
  • funding for core development

Also, what are the plans to take advantage of professional PMs* to:

  • (“project manager”) advance solutions to known deficiencies (like those above)
  • (“product/program manager”) identify what core dev efforts would benefit the community the most

Regarding that last PM bullet, core devs really care about the whole Python community and ecosystem, but they (mostly) don’t inherently have a clear picture of what the community needs most. That information is crucial for determining how to spend (limited) time to maximize positive impact. So instead core devs must more-or-less guess based on their experience and interactions with users, or follow the lead of someone else who has done so. (Sometimes core devs just work on something cool because, well, it’s cool…and that’s quite okay.) It’s just hard to know what will help the most people.

So, core devs (and the community) would benefit from a non-proscriptive list of concrete projects/objectives that would best serve the Python community and its different parts. (That includes beginners, experts, specialists, devops, data science, web devs, students, teachers, lib & app maintainers, embedders, etc.) I think that building and maintaining such a list would be a great use of professional PM resources, but does the steering council see it that way?

* “PM” means differently things to different people. “Product Manager”, “Program Manager”, and “Project Manager” are probably the most common. It also has different meaning depending on the context. Here I just mean someone who will use their specialized skills to discern what the community needs and to help drive certain projects forward.


As others have mentioned, among the many uses for which Python is popular, one of those is the learning and teaching of programming. Are there any specific plans to promote such uses in any way, such as collaborating with or supporting creators of learning systems and tools which use Python?

Thanks for all the questions!