Mailman 3 May 2018 - python-committers

GitHub: remove the "needs backport to 3.5" label?
by Victor Stinner 20 Aug '19

20 Aug '19

Hi, Python 3.5 entered security fix only mode. Should we now remove the "needs backport to 3.5" label? Other security only branches don't have this label neither (3.3 and 3.4). Victor

6 11

Licences for PyCharm and other JetBrains products
by Vinay Sajip 17 Dec '18

17 Dec '18

Recently I received 20 one-year licenses from JetBrains for the PyCharm IDE (Professional) and other JetBrains products (the licenses cover their "All Products Pack") for use in Python development. There are 11 licenses available - of the licenses I asked for last year, nine people took them up, so those are in use and come out of the allocation of 20. Those of you who took up the licences last time should find that the tools continue to work normally. The licences expire on 27 November 2018. If any others of you are interested in using these licenses, let me know off-list and I will forward the license access details to you. To access the licenses, you will need to have (or create) a JetBrains account. Regards, Vinay Sajip

2 1

Mentoring Office Hours - the idea, and a question
by Brian Curtin 27 Jul '18

27 Jul '18

Hey all, At the Language Summit last week, after Mariatta's talk we had a conversation around diversity and how to grow our contributor base, which led to someone (Steve Dower?) suggesting we post a sort of "Office Hours" list. This would be a list of current core developers who are interested in being available at set time(s) for helping mentor newer contributors in our community through our process and, if they're interested, mentoring them through the process of becoming core developers themselves. This "Office Hours" concept is a type of thing that has worked well elsewhere, including around the software world, and we have some people interested in offering said mentorship, so I would like to move on to getting this list up somewhere so we can start doing it. With that said, before I go make a PR to the devguide to start iterating on the implementation, an important question: As this is both an event similar to an in-person meetup and an event meant to be a safe space for those getting started, it will explicitly mention the code of conduct. As such, it needs a person/persons/list to contact should something arise in this context that needs to be handled. What/who should that be? * Suggestion 1: use the already in-place core-mentorship-owner(a)python.org, though I can't tell who's on there. * Suggestion 2: Create some new list with a few key people on it. * Suggestion 3: List some direct names. Who? As for implementation, there are some tools out there we could possibly use, but in the interests of getting something out there I'm just going to make a table and fill in some common information, starting with my own. Calendar apps and other integrations can come as we figure them out. Brian

3 5

A different way to focus discussions
by Guido van Rossum 11 Jul '18

11 Jul '18

Discussing PEPs on python-dev and python-ideas is clearly not scalable any more. (Even python-committers probably doesn't scale too well. :-) I wonder if it would make sense to require that for each PEP a new GitHub *repo* be created whose contents would just be a draft PEP and whose issue tracker and PR manager would be used to debate the PEP and propose specific changes. This way the discussion is still public: when the PEP-specific repo is created the author(s) can notify python-ideas, and when they are closer to submitting they can notify python-dev, but the discussion doesn't attract uninformed outsiders as much as python-{dev,ideas} discussions do, and it's much easier for outsiders who want to learn more about the proposal to find all relevant discussion. PEP authors may also choose to use a different repo hosting site, e.g. Bitbucket or GitLab. We can provide a script that allows checking the formatting of the PEP easily (basically pep2html.py from the peps repo). Using a separate repo per PEP has the advantage that people interested in a topic can subscribe to all traffic in that repo -- if we were to use the tracker of the peps repo you would have to subscribe to all peps traffic. Thoughts? (We can dogfood this proposal too, if there's interest. :-) -- --Guido van Rossum (python.org/~guido)

14 30

Comments on moving issues to GitHub
by Victor Stinner 02 Jun '18

02 Jun '18

Hi, I failed to get the microphone after Mariatta's secret talk about moving Python issues from bugs.python.org (Roundup) to GitHub. I just wanted to add that it's common (at least once per month) that someone comes to #python-dev to report that they cannot connect to bugs.python.org (the authentication is broken). Usually, I tried to point them to the meta-bug tracker, but I hate doing that... The concept of a meta-bug tracker blows my mind :-) Right now, I tied to add a comment on an issue and I got the error: """ Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request POST /issue32534. Reason: Error reading from remote server ________________________________ Apache/2.2.16 (Debian) Server at bugs.python.org Port 443 """ Sometimes, I get a SSL error. I reported the issue 7 months ago, and sometimes I still get the error: https://github.com/python/psf-infra-meta/issues/4 It's a random error, but using a loop, it's easy to reproduce it. I don't have a strong opinion about moving issues to GitHub. I just wanted to point out that if we keep bugs.python.org, we need more volunteers to maintain it. I would prefer to not have to redirect new comers, who want to report a simple bug, to a "meta bug tracker"... I don't plan to report the proxy error, since my previous bug report (SSL error) is still not fixed and it's the first time that I got this error. Victor

13 15

[RELEASE] Python 3.7.0b5 bonus beta!
by Ned Deily 31 May '18

31 May '18

A 3.7 update: Python 3.7.0b5 is now the final beta preview of Python 3.7, the next feature release of Python. 3.7.0b4 was intended to be the final beta but, due to some unexpected compatibility issues discovered during beta testing of third-party packages, we decided to revert some changes in how Python's 3.7 Abstract Syntax Tree parser deals with docstrings; 3.7.0b5 now behaves like 3.6.x and previous releases (refer to the 3.7.0b5 changelog for more information). **If your code makes use of the ast module, you are strongly encouraged to test (or retest) that code with 3.7.0b5, especially if you previously made changes to work with earlier preview versons of 3.7.0.** As always, please report issues found to bugs.python.org as soon as possible. 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 (and final, we hope!) preview release will be the release candidate which is now planned for 2018-06-11, followed by the official release of 3.7.0, now planned for 2018-06-27. You can find Python 3.7.0b5 and more information here: https://www.python.org/downloads/release/python-370b5/ -- Ned Deily nad(a)python.org -- []

1 0

FINAL WEEK FOR 3.7.0 CHANGES!
by Ned Deily 30 May '18

30 May '18

This is it! We are down to THE FINAL WEEK for 3.7.0! Please get your feature fixes, bug fixes, and documentation updates in before 2018-05-21 ~23:59 Anywhere on Earth (UTC-12:00). That's about 7 days from now. We will then tag and produce the 3.7.0 release candidate. Our goal continues been to be to have no changes between the release candidate and final; AFTER NEXT WEEK'S RC1, CHANGES APPLIED TO THE 3.7 BRANCH WILL BE RELEASED IN 3.7.1. Please double-check that there are no critical problems outstanding and that documentation for new features in 3.7 is complete (including NEWS and What's New items), and that 3.7 is getting exposure and tested with our various platorms and third-party distributions and applications. Those of us who are participating in the development sprints at PyCon US 2018 here in Cleveland can feel the excitement building as we work through the remaining issues, including completing the "What's New in 3.7" document and final feature documentation. (We wish you could all be here.) As noted before, the ABI for 3.7.0 was frozen as of 3.7.0b3. You should now be treating the 3.7 branch as if it were already released and in maintenance mode. That means you should only push the kinds of changes that are appropriate for a maintenance release: non-ABI-changing bug and feature fixes and documentation updates. If you find a problem that requires an ABI-altering or other significant user-facing change (for example, something likely to introduce an incompatibility with existing users' code or require rebuilding of user extension modules), please make sure to set the b.p.o issue to "release blocker" priority and describe there why you feel the change is necessary. If you are reviewing PRs for 3.7 (and please do!), be on the lookout for and flag potential incompatibilities (we've all made them). Thanks again for all of your hard work towards making 3.7.0 yet another great release - coming to a website near you on 06-15! Release Managerly Yours, --Ned https://www.python.org/dev/peps/pep-0537/ -- Ned Deily nad(a)python.org -- []

11 32

Triage perms for Elvis
by R. David Murray 30 May '18

30 May '18

At Yuri's request I've given Elvis triage privileges on the tracker. I don't anticipate any objections, given the work he's done on What's New and other things. --David

5 4

Python 3.7.0 updated schedule: beta 5 cutoff in 24 hours
by Ned Deily 29 May '18

29 May '18

Here's an update on the 3.7.0 endgame. As announced several days ago, we made the difficult decision to hold back on 3.7.0rc1 due primarily to some unexpected difficulties being seen downstream due to changes in how docstrings were handled in 3.7.0 (details below). After some discussions about various approaches, we agreed on a solution that should minimize downstream impact without losing all the benefits of the existing 3.7 changes. Thanks to a lot of work over the long weekend by a number of people that solution is now merged in the 3.7 branch. In parallel with that, a number of people spent a lot of time looking at CI and buildbot test failures, mostly intermittent ones. As a result, a number of actual bugs were fixed and also problems with a number of tests were fixed which should make the test suite more robust. All this is good news. Primarily because of the important user-facing changes made with the AST docstring API, I feel we need to do one more beta release before we are ready for the release candidate. About 24 hours from now, approximately 2018-05-30 18:00UTC, I plan to tag and start manufacturing 3.7.0b5. This will be a short beta cycle, aimed mainly at users of the AST API so they can recheck that their packages with 3.7.0. Assuming all goes well, we will then plan to tag 3.7.0rc1 on 2018-06-11 and 3.7.0 final on 2017-06-27. I am also rescheduling 3.6.6rc1 and 3.6.6 final to match the new 3.7.0 dates. All fixes that have been merged into the 3.7 branch as of cutoff tomorrow will be in 3.7.0b5 and fixes merged afterwards will be in 3.7.0rc1 up to its cutoff point. After 3.7.0rc1 cutoff, 3.7 merges will appear in 3.7.1. Please continue to exercise diligence when deciding whether a change is appropriate for 3.7; as a rule of thumb, treat the 3.7 branch as if it were already released and in maintenance mode. Please also pay attention to CI test failures and buildbot test failures and see if you can help resolve them. I want to thank everyone who has been involved so far in helping us through this endgame and who have given up their personal time to work on making Python better. I, for one, am deeply grateful. 2018-05-30 3.7.0b5 2018-06-11 3.7.0rc1 & 3.6.6rc1 2018-06-27 3.7.0final & 3.6.6final --Ned On May 25, 2018, at 01:33, Ned Deily <nad(a)python.org> wrote: > On May 24, 2018, at 03:23, Ned Deily <nad(a)python.org> wrote: >> On May 23, 2018, at 09:13, Ned Deily <nad(a)python.org> wrote: >>> On May 23, 2018, at 07:45, Serhiy Storchaka <storchaka(a)gmail.com> wrote: >>>> Is it possible to add yet one beta instead? >>>> CI was broken for few latest days, tests are not passed on my computer still (and fail on some buildbots), updating What's New exposed new features which need additional testing (and maybe fixing or reverting), and I'm not comfortable about some changes which would be harder to fix after the release. >>> it is possible but there's no point in doing either another beta or a release candidate until we understand and address the current blocking issues, like the major buildbot failures. We have another 24 hours until rc1 was planned to be tagged. Let's keep working on the known issues and we will make a decision then. >> An update: thanks to a lot of effort over the past day by a number of >> people (including Victor, Serhiy, Christian, Zach, and others I'm sure >> I'm forgetting - my apologies), we have addressed all of the "release >> blocker" issues and all but one of the persistent failures on the 3.7 >> stable buildbots. We should have the couple of remaining "deferred >> blockers" including the remaining stable buildbots in green status by >> later today. At that point, we will be ready to tag 3.7.0rc1 and begin >> producing the release candidate artifacts. > Further update: some good news and some changes. > > The good news is that we have resolutions for all of the previous release and deferred blockers. Thanks to a number of people for continuing to help get the remaining stable buildbot issues taken care of along with some lingering bugs. > > The not-quite-as-good news is that we have had more discussions about some unexpected incompatibilities that have shown up with downstream user testing with the AST docstrings changes in place (see bpo-32911). We have had some previous discussions about the expected user impact and, earlier in the beta phase, I encouraged us to stay the course with the feature as implemented. But I am now persuaded that we owe it to our users to take one more look at this to make sure we do not force them to make changes for 3.7 and then once again for 3.8. More details are in the bug tracker issue; I strongly encourage those of us who have been involved with this to "vote" there on the proposal to either (A) proceed with the release of the current implementation in 3.7.0 or (B) revert the feature in 3.7.0 and retarget for 3.8. Should the consensus be to revert (B), we will plan to have one more fast-track beta release (b5) prior to the release candidate, in order to allow downstream users to tes > t their projects with the removal. PLEASE, keep the discussion about this on the bug tracker (and not here!) and keep it brief so we can move forward quickly. Because of the upcoming 3-day holiday weekend in some countries, I have set Tue 2018-05-29 18:00 UTC as a cutoff for "voting" but, if a clear consensus emerges earlier, we will likely cut the discussion short. So chime in now on the bug tracker if you have a stake in this issue. > > https://bugs.python.org/issue32911 > > This does mean that yesterday's "last chance" has been extended a bit, at most a few days. I will let you know as soon as we have made a decision about the feature and will provide updated 3.7.0 schedule info at that time. -- Ned Deily nad(a)python.org -- []

1 0

Re: [python-committers] [Python-Dev] Troubles to merge changes in the 2.7 branch: PR "out-of-date" branch
by Ned Deily 28 May '18

28 May '18

On May 28, 2018, at 13:19, Nathaniel Smith <njs(a)pobox.com> wrote: > > Isn't that what happens if someone enables the check box at Repository Settings -> Branches -> Branch protection rules -> [pick a branch] -> Require branches to be up to date before merging ? Hmm, for some some reason, it appears that, at the moment, the 2.7, 3.4, and 3.5 branches have that option set, while 3.6, 3.7, and master don't. I'm not sure how we got to that state. Any other reasons to prefer on versus off? On Mon, May 28, 2018, 09:11 Brett Cannon <brett(a)python.org> wrote: > Ryan is right that there's no special setting in GitHub at least which would make merging more strict for certain branches as you're describing. > > On Mon, 28 May 2018 at 07:06 Ryan Gonzalez <rymg19(a)gmail.com> wrote: > AFAIK there's no setting like this available, and I've done this many times > on other repos with no trouble. Maybe it could be a GitHub bug? > > On May 28, 2018 4:59:03 AM Victor Stinner <vstinner(a)redhat.com> wrote: > > > Hi, > > > > Since one or two weeks, I noticed that it's difficult to merge pull > > requests into the 2.7 branch. If a different commit is pushed in the > > meanwhile (if a different PR has been merged), the 2.7 branch diverges > > and the PR is immediately marked as "This branch is out-of-date with > > the base branch" and the "Squash and Merge" button is disabled (grey). > > > > For example my PR https://github.com/python/cpython/pull/7120 which > > changes Lib/test/regrtest.py cannot be merged because a commit > > touching the documentation (Doc/ directory) has been merged after I > > posted my PR and before the CI completed. > > > > I don't see the same behavior on the master branch. Is the 2.7 branch > > configured as more strict? -- Ned Deily nad(a)python.org -- []

1 0