Mailman 3 May 2018 - python-committers

AppVeyor and Travis-CI
by Eric V. Smith 16 May '18

16 May '18

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 Travis-CI. https://github.com/python/cpython/pull/6844 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: ====================================================================== FAIL: test_stdin_broken_pipe (test.test_asyncio.test_subprocess.SubprocessSafeWatcherTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/travis/build/python/cpython/Lib/test/test_asyncio/test_subprocess.py", line 214, in test_stdin_broken_pipe self.loop.run_until_complete, coro) 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. Thanks. Eric

6 11

Proposing Mark Shannon to be a core developer
by Larry Hastings 15 May '18

15 May '18

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, //arry/

18 19

Idea: Create subteams?
by Victor Stinner 15 May '18

15 May '18

Hi, 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 yourself. 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: * Documentation * IDLE * asyncio Maybe you see more candidates? Victor

4 4

Orphaned backports
by Serhiy Storchaka 14 May '18

14 May '18

miss-islington is an awesome bot! It makes fixing bugs in multiple versions much simpler. You need just accept automatically created backporting PRs. But there is a downside. miss-islington makes the life so easier, that sometimes you forgot about not finished backports. miss-islington can fail to backport some changes for different reasons. Currently on GitHub there are tens merged PRs labeled for backporting, but backports were not finished. Please take attention if your PRs in one of the following lists: https://github.com/python/cpython/pulls?q=label%3A%22needs+backport+to+3.7%… https://github.com/python/cpython/pulls?q=label%3A%22needs+backport+to+3.6%… https://github.com/python/cpython/pulls?q=label%3A%22needs+backport+to+2.7%…

4 7

Results of the poll: Do you like the PEP 572 Assignment Expressions?
by Victor Stinner 09 May '18

09 May '18

Hi, As announced last week, I publish the result of the poll I started on the *current* Chris Angelico's PEP 572 "Assignment Expressions": https://www.python.org/dev/peps/pep-0572/ Results: * 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 Victor

1 0

Poll: Do you like the PEP 572 Assignment Expressions?
by Victor Stinner 08 May '18

08 May '18

Hi, 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: https://www.python.org/dev/peps/pep-0572/ 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 February) :-) 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 ;-) Victor

33 38

PEP 572 at the Language Summit next week
by Victor Stinner 04 May '18

04 May '18

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 discussion. 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. Victor

4 4

My opinion about "binding expressions" (was Poll: Do you like the PEP 572 Assignment Expressions?)
by Eric Snow 04 May '18

04 May '18

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. -eric * 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... <wink>

1 0

[RELEASE] Python 3.7.0b4, final 3.7 beta, now available for testing
by Ned Deily 03 May '18

03 May '18

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: https://www.python.org/downloads/release/python-370b4/ -- Ned Deily nad(a)python.org -- []

1 0