(Context: Continuing to prepare for the core dev sprint next week. Since
the sprint is near, *I'd greatly appreciate any quick comments, feedback
Following up my collection of past beginning contributor experiences, I've
collected these experiences in a dedicated GitHub repo and written a
(subjective!) summary of main themes that I recognize in the stories, which
I've also included in the repo.
A "TL;DR" bullet list of those main themes:
* Slow/no responsiveness
* Long, slow process
* Hard to find where to contribute
* Mentorship helps a lot, but is scarce
* A lot to learn to get started
* It's intimidating
More specifically, something that has come up often is that maintaining
momentum for new contributors is crucial for them to become long-term
contributors. Most often, this comes up in relation to the first two
points: Suggestions or PRs are completely receive no attention at all
("ignored") or stop receiving attention at some point ("lost to the void").
Unfortunately, the probability of this is pretty high for any issue/PR, so
for a new contributor this is almost guaranteed to happen while working on
one of their first few contributions. I've seen this happen many times, and
have found that I have to personally follow promising contributors' work to
ensure that this doesn't happen to them. I've also seen contributors learn
to actively seek out core devs when these situations arise, which is often
a successful tactic, but shouldn't be necessary so often.
Now, this is in large part a result of the fact that us core devs are not a
very large group, made up almost entirely of volunteers working on this in
their spare time. Last I checked, the total amount of paid development time
dedicated to developing Python is less than 3 full-time (i.e. ~100 hours a
The situation being problematic is clear enough that the PSF had concrete
plans to hire paid developers to review issues and PRs. However, those
plans have been put on hold indefinitely, since the PSF's funding has
shrunk dramatically since the COVID-19 outbreak (no PyCon!).
So, what can be done? Besides raising more funds (see a note on this
below), I think we can find ways to reduce how often issues/PRs become
"stalled". Here are some ideas:
1. *Generate reminders for reviewers when an issue or PR becomes "stalled'
due to them.* Personally, I've found that both b.p.o. and GitHub make it
relatively hard to remember to follow up on all of the many issues/PRs
you've taken part in reviewing. It takes considerable attention and
discipline to do so consistently, and reminders like these would have
helped me. Many (many!) times, all it took to get an issue/PR moving
forward (or closed) was a simple "ping?" comment.
2. *Generate reminders for contributors when an issue or PR becomes
"stalled" due to them.* Similar to the above, but I consider these separate.
3. *Advertise something like a "2-for-1" standing offer for reviews.* This
would give contributors an "official", acceptable way to get attention for
their issue/PR, other than "begging" for attention on a mailing list. There
are good ways for new contributors to be of significant help despite being
new to the project, such as checking whether old bugs are still relevant,
searching for duplicate issues, or applying old patches to the current code
and creating a PR. (This would be similar to Martin v. Löwis's 5-for-1
offer in 2012, which had little success but lead to some interesting
4. *Encourage core devs to dedicate some of their time to working through
issues/PRs which are "ignored" or "stalled".* This would require first
generating reliable lists of issues/PRs in such states. This could be in
various forms, such as predefined GitHub/b.p.o. queries, a dedicated
web-page, a periodic message similar to b.p.o.'s "weekly summary" email, or
dedicated tags/labels for issues/PRs. (Perhaps prioritize "stalled" over
- Tal Einat
As was mentioned many times on the list, PEP634-PEP636 are thoroughly
prepared and good materials, many thanks to their authors. PEP635
"Motivation and Rationale" (https://www.python.org/dev/peps/pep-0635/)
stands out among the 3 however: while reading it, chances that you'll
get a feeling of "residue", accumulating a section over section. By the
end of reading, you may get a well-formed feeling that you've read a
half-technical, half-marketing material, which is intended to "sell" a
particular idea among many other very viable ideas, by shoehorning some
concepts, downplaying other ideas, and at the same time, light-heartedly
presenting drawbacks of its subject one.
Just to give one example, literally at the very beginning, at the
"Pattern Matching and OO" section (3rd heading) it says:
> Pattern matching is complimentary to the object-oriented paradigm.
It's not until the very end of document, in the "History and Context" it
tells the whole truth:
> With its emphasis on abstraction and encapsulation, object-oriented
> programming posed a serious challenge to pattern matching.
You may wonder how "complimentary" and "posed a serious challenge"
relate to each other. While they're definitely not contradictory,
starting the document with light-hearted "complimentary" can be seen as
trying to set the stage where readers don't pay enough attention to the
problem. And it kinda worked: only now  wider community discovers the
implications of "Class Patterns" choices. (As a note, PEP635 does well
on explaining them, and I'm personally sold on that, but it's *tough*
choice, not the *obvious* choice).
There're many more examples like that in the PEP635, would take too
much space to list them all. However, PEP635 refers to the paper:
> Kohn et al., Dynamic Pattern Matching with Python
> https://doi.org/10.1145/3426422.3426983 (Accepted by DLS 2020. The
> link will go live after Nov. 17; a preview PDF can be obtained from
> the first author.)
As that citation suggests, the paper is not directly linked from the
PEP635. But the preprint is now accessible from the conference page,
https://conf.researchr.org/home/dls-2020?#event-overview (direct link
as of now: https://gvanrossum.github.io//docs/PyPatternMatching.pdf).
That paper is written at much higher academic standard, and a pleasure
to read. I recommend it to everyone who read PEP635 (note that it was
written with PEP622 in mind, but conceptual differences are minor). With
it, I noticed just 2 obvious issues:
Section 4.3. Named Constants
> It would clearly be desirable to allow named constants in patterns
> as a replacement and extension of literals. However, Python has no
> concept of a constant, i.e. all variables are mutable (even where
> the values themselves are immutable).
So, unlike PEP635, the paper pinpoints right the root of PEP634's
problems: lack of constants in Python (on the language level). This is
just the point which was raised on the mailing list either
Under strict academic peer review, the paper would have been returned
for elaboration, with a note like: "Given that nowadays many dynamic
lack of constants poses a serious usability challenge to your proposal,
please explain why you chose to proceed anyway (and apply workarounds),
instead of first introducing the concept of constants to the language.
(Given that amount of work to implement pattern matching is certainly
an order of magnitude larger than to introduce constants)."
But the paper wasn't returned for elaboration, so we'll keep wondering
why the authors chose such a backward process.
Section 6.1. Scope
> The granularity of the scope of local variables is at the level of
> functions and frames. [...]
> The only way to restrict the scope of a variable to part of a
> function’s body (such as a case clause) would be to actively delete
> the variable when leaving the block. This would, however, not restore
> any previous value of a local variable in the function’s scope.
This is a misconception ("the only way") which is repeated almost one
to one on PEP635 either. If anything, the above describes how
pseudo-scoping is currently implemented for exception vars in "except
Exception as e:" clause (more info:
which is hardly a "best practice", and definitely not the only way.
How to support multiple variable scopes in one stack frame is not a
rocket science at all. One just need to remember how C did that since
~forever. And that's: (for unoptimized programs) variables in different
scopes live in disjoint subsections of a frame. (For optimized
programs, variables with disjoint liveness can share the same
locations in a frame).
The only reasons for not implementing the same solution in Python would
be intertia of thought and "but it's not done anywhere else in
Python". Yeah, but nobody del'eted local variables behind users' backs
either, before somebody started to do that for exception clause
variables. And the whole of pattern matching is such that either one
thing, or another, but will be done for the first time in Python. For
example, nobody before could imagine that one can write "Point(x, y)",
and get x and y assigned, and now we're facing just that . (Again,
I personally love it, though think that "Point(>x, >y)" is an
interesting option to address the tensions).
In that regard, the current PEP634 and friends miss too many interesting
and useful opportunities (constants in language core and true scoping
for match'es, to name a few). Well, that happens. But they try to
shoehorn too much of "we didn't do" into "it's not possible" or "it
doesn't make sense", or "let's workaround it in adhoc ways" and that
raises eyebrows, leading to concerns of whether the proposals are
actually "raw" as of yet.
 People expressing surprise at "Class Patterns" syntax:
> I'd love to have an easy way to keep them in the loop.
I'm one of the maintainers on https://github.com/docker-library/python
(which is what results in https://hub.docker.com/_/python), and I'd
love to have an easy way to keep myself in the loop too! O:)
Is there a lower-frequency mailing list where things like this are
normally posted that I could follow?
(I don't want to be a burden, although we'd certainly really love to
have more upstream collaboration on that repo -- we do our best to
represent upstream as correctly/accurately as possible, but we're not
> would it make sense to add a packaging section to our documentation or
> to write an informational PEP?
FWIW, I love the idea of an explicit "packaging" section in the docs
(or a PEP), but I've maintained that for other projects before and
know it's not always easy or obvious. :)
4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4
PS. thanks doko for giving me a link to this thread! :D
I just wanted to express some appreciation for the excellent Dev Guide.
I don't use git or github much, but the dev guide got me from not knowing
where to start, to having a PR out for review in a couple hours. It walked
me through...pretty much perfectly.
Getting a CLA signed was also simple and nice. When the bot brought that
up, I thought it'd be a headache big enough to keep the PR from
ever getting back to the top of my todo list. But the help text and links
from the bot, the integration of BPO with Google sign in, linking BPO to a
github name, digitally signing the CLA, the little heroku thing -- all just
self serve, and easy, and obvious, and really just didn't get in the way.
I don't know which person(s) are the best to thank for all that, but thanks
for making it easy for a newbie to get started and contribute.
A couple of questions about the DLS 2020 paper.
1. Why do you use the term "validate" rather than "test" for the process
of selecting a match?
It seems to me, that this is a test, not a validation, as no exception
is raised if a case doesn't match.
2. Is the error in the ast matching example, an intentional
"simplification" or just an oversight?
case BinOp(Num(left), '+', Num(right)):
return Num(left + right)
case BinOp(left, '+' | '-', Num(0)):
case UnaryOp('-', UnaryOp('-', item)):
The correct version is
case BinOp(Num(left), Add(), Num(right)):
return Num(left + right)
case BinOp(left, Add() | Sub(), Num(0)):
case UnaryOp(USub(), UnaryOp(USub(), item)):
We are using doctest to give our developers easy access to write very
fast unit tests and encourage "tests as documentation".
Recently we hit an issue where doctest crashes on certain objects that
fail to "unwrap".
Looking at the code and reasoning behind the crash it seems like we can
simply ignore a failed call to unwraps.
There is now a PR open against against trunk and 3.8 branch (happy to
make a 3.9 branch PR as well) here:
Does anyone have time to review and/or comment on this?
A few days ago, Terry J. Reedy created the issue about the formatter module.
The issue is mainly about testing code but also discussing the removal of
I noticed that the formatter module was deprecated in 3.4 and it was
originally scheduled to be removed in 3.6. But the removal was delayed
until 2.7 EOL.
Now 2.7 is EOL and there is no usage in stdlib.
So IMHO, it is good to remove the formatter module in 3.10
So before removing it, I would like to hear the concern.