I accidentally checked in some test files, and they got backported to
3.7. I pushed a commit to delete them, and it was committed to master.
But in the 3.7 backport, something has gone wrong with AppVeyor and
AppVeyor says "Expected — Waiting for status to be reported". There's no
obvious way to get it to actually report the status, or to restart.
There is no "Details" button listed on the PR page.
For Travis-CI, Miss Isslington sent me an email that says "Backport
status check is done, and it's a failure ❌ ." The Travis-CI log file
ends with a timeout:
Traceback (most recent call last):
line 214, in test_stdin_broken_pipe
AssertionError: (<class 'BrokenPipeError'>, <class
'ConnectionResetError'>) not raised by run_until_complete
I'm sure this is all due to the heavy load the systems are under. I
can't find a way to kick both of these off again. I couldn't find
anything in the devguide, but if I missed it please let me know.
Dr. Mark Shannon contributed the "key sharing dictionary" to Python,
writing both the PEP and the implementation. This shipped in Python 3.3
and was listed as one of the top features of that release as according
to the "What's New?" document.
We've asked Mark in the past if he'd be interested in becoming a core
developer--and he actually said no. At the time he said he didn't like
our antiquated workflow. Now that we've switched to the git-based core
dev workflow, this objection is gone, and he's now interested in
accepting the commit bit and the responsibilities that it entails.
I suspect you, my colleagues in CPython core development, will be
surprised at the current state of affairs. I'm expecting a load of "you
mean Mark *isn't* a core developer yet?" replies.
Submitted for your consideration,
While thinking about how to get more contributors onboard, I
identified that one bottleneck is building trust. Currently, a vote to
promote a contributor as a core dev requires the approval of almost
all active core developers, and this list is quite large (50 people?
more?). It takes a lot of time until a contributor is known by enough
people to start the process to promote them as a core dev.
My idea is to create subteams which would have less permission than
"everything": restrict changes to specific directories. It seems like
in practice, we already have such subteams: Documentation, IDLE and
asyncio have a dedicated Component in the bug tracker, their own
directories, a group of people focused on these components, and
even... a dedicated mailing list!
The restriction would be the ability to merge a pull request. Since
miss-ilington recently got the power of merging a PR, it makes me
think that it's doable to allow "non core" people to merge a change
under certain conditions. For example, let's say that a contributor
called "Alice" is part of a subteam. If Alice approves a change in the
review, added the "approved" label and the CI pass: a bot can merge
the change, since Alice is allowed to merge a PR modifying specific
directories.If Alice doesn't have the power, the bot may notice Alice
that she lacks permission and the bot may remove the label.
IMHO it's better to have two steps to merge: approval in the review
and a label, sometimes a change looks good but should not be merged
yet, or you don't want to take the responsibility to merge it
What about current core developers? No change for them, they keep
their "super power" to modify everything.
If a member of a subteam shows interest to do more than only working
in a subteam, the usual promotion process with a vote on
python-committers can be followed.
My expectation is that it will be faster to promote a contributor into
a subteam. It's easier to trust someone if they is only allowed to
modify some directories. In my experience, people with the same
interest find their way to meet other people working on the same
topic. The trust is built naturally in a component.
You may see a parallel with the Linux kernel hierarchy and Linux
subsystems, but the proposed organization is different. In Python, the
tradition is that everybody works in the same repository. I don't want
to change that.
What do you think? Do you like the idea of subteams? Is it feasible
(the label and the bot things)?
I identified 3 obvious subteams:
Maybe you see more candidates?
As announced last week, I publish the result of the poll I started on
the *current* Chris Angelico's PEP 572 "Assignment Expressions":
* Like (+1): 3 (8%)
* Dislike (-1): 29 (76%)
* No opinion (0): 6 (16%)
Percents if you ignore no opinion:
* Like (+1): 3 (9%)
* Dislike (-1): 29 (91%)
Two people voted on a variant of the PEP, so I excluded from my results:
* Steven D'Aprano: With the changes suggested by Guido, +1
* Ethan Furman: With Tim's and Guido's latest suggestions, +1
Again, it was just a poll. Not a vote. Multiple people also added a
second vote for a variant of the PEP. I only counted results on the
current PEP version.
It seems like "Tim's and Guido's latest suggestions" have big impact
and are awaited :-)
Like, vote: +1
* Stefan Krah
* Tim Peters
* Jason R. Coombs
Dislike, vote: -1
* Victor Stinner
* Antoine Pitrou
* Tal Einat
* Jack Jansen
* Berker Peksağ
* M.-A. Lemburg
* Alex Gaynor
* Nick Coghlan
* Paul Moore
* Eric Snow
* Yury Selivanov
* Facundo Batista
* Alexander Belopolsky
* Łukasz Langa
* Stefan Richthofer
* Julien Palard
* Serhiy Storchaka
* Terry Reedy
* Steve Dower
* Raymond Hettinger
* Christian Heimes
* Gregory P. Smith
* Mark Dickinson
* Nathaniel Smith
* Carol Willing
* Kushal Das
* Larry Hastings
* Senthil Kumaran
* Andrew Svetlov
No opinion, vote: 0
* INADA Naoki
* Ivan Levkivskyi
* Chris Jerdonek
* Barry Warsaw
* Ned Deily
* Robert Collins
I would like to start a poll on Chris Angelico's PEP 572 "Assignment
Expressions", restricted to Python core developers, to prepare the
talk at the Language Summit:
The poll is on the *current* PEP. I propose 4 choices:
* +1: you like the PEP
* -1: you dislike the PEP
* 0: you are not sure if you like it or not, or you have no opinon
* don't reply to this poll :-)
Just reply to this email with "+1", "0", "-1". Please don't elaborate
here, it's just a quick poll, use python-dev if you want to talk :-)
The poll will end next Tuesday, May 8, the day before the Language Summit.
I propose a poll because I'm unable to track the opinion of each core
dev, too many emails have been sent to python-dev, and maybe some
people changed their mind during the long discussion (which started in
Note: Obviously, it's just a poll, not a vote. Guido van Rossum is the
one who will pronounce himself on the PEP, to accept to reject it, so
the only one allowed to vote ;-)
Sorry, I choose to reply to python-committers rather than python-dev
because I have been annoyed by the PEP 572 traffic on python-dev.
2018-04-29 22:45 GMT+02:00 Larry Hastings <larry(a)hastings.org>:
> In case it helps, we're planning on presentations on / a discussion of PEP
> 572 at the 2018 Python Language Summit next Wednesday. (I'm assuming it
> won't be pronounced upon before then--after all, what's the rush?)
> Naturally the discussion isn't going to escape the room until it gets
> reported on by Jake Edge, but delegates at the Summit will hopefully emerge
> well-informed and comfortable with the result of the discussion.
Who is going to lead this discussion? Will we have at least one
developer in favor of the PEP to give a summary of the advantages? I
would like to make sure that we can get a fair summary of the past PEP
I'm not worried for the "dislike" part which may be correctly represented :-D
Note: I just got a notice of a strike at Air France next Tuesday, the
day I'm flighting to the US, and my 3rd and last flight of this trip
is cancelled. Oh oh.
On Wed, May 2, 2018 at 3:49 AM, Victor Stinner <vstinner(a)redhat.com> wrote:
> I propose a poll because I'm unable to track the opinion of each core
> dev, too many emails have been sent to python-dev, and maybe some
> people changed their mind during the long discussion (which started in
> February) :-)
Victor said "Please don't elaborate here" so I've opened yet another*
thread for this topic. :) My apologies to all for that. However, I
didn't feel like the poll captured my opinion well. In the interest
of not adding too much more noise to the discussion on this specific
topic, I'll provide a (relatively) brief opinion here and then bow
out. (I don't feel like I have anything else to contribute on the
subject.) If you feel similarly, feel free to do likewise (e.g. be
concise). Please don't engage in discussion here. There are plenty
of other threads for that. If no one else registers their opinion
here that's fine with me too. :)
As to my actual opinion, ultimately I don't think "binding
expressions" are such a big deal either way. I doubt abuse will be as
common or frustrating as that of list comprehensions and ternary
expressions; but either way code review will mitigate that risk (and I
doubt binding expressions will be a major distraction there). Anyway,
I'll probably use them occasionally if we get them.
* Yeah, it's like when someone says "the problem is there are too many
file formats" so they write their own to render the rest irrelevant...
Python 3.7.0b4 is the final beta preview of Python 3.7, the next feature
release of Python. Beta releases are intended to give you the
opportunity to test new features and bug fixes and to prepare your
projects to support the new feature release. We strongly encourage you
to test your projects with 3.7 during the beta phase and report issues
found to bugs.python.org as soon as possible. While the release is
feature complete entering the beta phase, it is possible that features
may be modified or, in rare cases, deleted up until the start of the
release candidate phase. Please keep in mind that this is a preview
release and its use is not recommended for production environments.
Attention macOS users: there is now a new installer variant for macOS
10.9+ that includes a built-in version of Tcl/Tk 8.6. This variant is
expected to become the default version when 3.7.0 releases. Check it out!
The next preview release will be the release candidate and is planned
for 2018-05-21 followed by the official release of 3.7.0, planned for
2018-06-15. You can find Python 3.7.0b4 and more information here:
nad(a)python.org --