python-committers September 2017

python-committers@python.org

23 participants
16 discussions

Py_UNREACHABLE
by Barry Warsaw 15 Sep '17

15 Sep '17

I landed bpo-31338 / PR #3374 which adds a Py_UNREACHABLE() macro to master, along with some additional documentation in the C API describing this and a few other common macros. If you’re writing or reviewing C changes that include unreachable code paths, please use this macro for consistency, instead of other approaches like assert() (which can be compiled out) and `return NULL`, etc. As part of the PR, I changed a bunch of existing instances in the code: https://github.com/python/cpython/pull/3374/files If you find any cases I’ve missed, feel free to submit a PR and I will happily review it. I think this makes our code more consistent and ultimately safer. (Thanks Victor for the PR review!) Cheers, -Barry

2 2

PEP 549 v2: now titled Instance Descriptors
by Larry Hastings 08 Sep '17

08 Sep '17

I've updated PEP 549 with a new title--"Instance Descriptors" is a better name than "Instance Properties"--and to clarify my rationale for the PEP. I've also updated the prototype with code cleanups and a new type: "collections.abc.InstanceDescriptor", a base class that allows user classes to be instance descriptors. //arry/

1 0

Cherry picker bot deployed in CPython repo
by Mariatta Wijaya 07 Sep '17

07 Sep '17

Hi, The cherry picker bot has just been deployed to CPython repo, codenamed miss-islington. miss-islington made the very first backport PR for CPython and became a first time GitHub contributor: https://github.com/python/cpython/pull/3369 GitHub repo: https://github.com/python/miss-islington What is this? ========== As part of our workflow, quite often changes made on the master branch need to be backported to the earlier versions. (for example: from master to 3.6 and 2.7) Previously the backport has to be done manually by either a core developer or the original PR author. With the bot, the backport PR is created automatically after the PR has been merged. A core developer will need to review the backport PR. The issue was tracked in https://github.com/python/core-workflow/issues/8 How it works ========== 1. If a PR needs to be backported to one of the maintenance branches, a core developer should apply the "needs backport to X.Y" label. Do this **before** you merge the PR. 2. Merge the PR 3. miss-islington will leave a comment on the PR, saying it is working on backporting the PR. 4. If there's no merge conflict, the PR should be created momentarily. 5. Review the backport PR created by miss-islington and merge it when you're ready. Merge Conflicts / Problems? ====================== In case of merge conflicts, or if a backport PR was not created within 2 minutes, it likely failed and you should do the backport manually. Manual backport can be done using cherry_picker: https://pypi.org/project/cherry-picker/ Older merged PRs not yet backported? ============================== At the moment, those need to be backported manually. Don't want PR to be backported by a bot? ================================ My recommendation is to apply the "needs backport to X.Y" **after** the PR has been merged. The label is still useful to remind ourselves that this PR still needs backporting. Who is Miss Islington? ================= I found out from Wikipedia that Miss Islington is the name of the witch in Monty Python and The Holy Grail. miss-islington has not signed the CLA! ============================= A core dev can ignore the warning and merge the PR anyway. Thanks! Mariatta Wijaya

4 4

Python 3.3.7rc1 now available prior to Python 3.3 end-of-life
by Ned Deily 07 Sep '17

07 Sep '17

On behalf of the Python development community and the Python 3.3 release teams, I would like to announce the availability of Python 3.3.7rc1, the release candidate of Python 3.3.7. It is a security-fix source-only release. Python 3.3.0 was released 5 years ago on 2012-09-29 and has been in security-fix-only mode since 2014-03-08. Per project policy, all support for the 3.3 series of releases ends on 2017-09-29, five years after the initial release. Therefore, Python 3.3.7 is expected to be the final release of any kind for the 3.3 series. After 2017-09-29, **we will no longer accept bug reports nor provide fixes of any kind for Python 3.3.x**; of course, third-party distributors of Python 3.3.x may choose to offer their own extended support. Because 3.3.x has long been in security-fix mode, 3.3.7 may no longer build correctly on all current operating system releases and some tests may fail. If you are still using Python 3.3.x, we **strongly** encourage you to upgrade to a more recent, fully supported version of Python 3; see https://www.python.org/downloads/. If you are still using your own build of Python 3.3.x , please report any critical issues with 3.3.7rc1 to the Python bug tracker prior to 2017-09-18, the expected release date for Python 3.3.7 final. Even better, use the time to upgrade to Python 3.6.x! Thank you to everyone who has contributed to the success of Python 3.3.x over the past years! You can find Python 3.3.7rc1 here: https://www.python.org/downloads/release/python-337rc1/ -- Ned Deily nad(a)python.org -- []

1 0

Workflow change reminder: The Blurb Has Landed
by Larry Hastings 05 Sep '17

05 Sep '17

Yesterday I "blurbified" the 2.7, 3.6, and master branches in CPython. It's finally official: all* branches have now been "blurbified". This means that Misc/NEWS is no longer present in any of CPython's active branches. Instead, Misc/NEWS has been broken up into a zillion little files in the new Misc/NEWS.d directory tree. (Misc/NEWS can be reconstituted consistently from this directory tree.) This banishes forever the annoying problem of Misc/NEWS merge conflicts when you attempt to merge a pull request, when release managers create a release, etc. We announced "blurb" a month or two back, and you should already be creating your news entries in Misc/NEWS.d. But just in case, here's a quick refresher. The core-workflow team has created a tool called "blurb" that makes it easy to create a news entry for a commit. It's easy to install and use. You can install it with: python3 -m pip install blurb It requires Python 3.5 or newer. (Sorry, it can't get backported to 3.4 without fixing a bug in "re"... and 3.4 is closed for bugfixes.) To create a news entry, just run blurb from anywhere inside your CPython repo. On POSIX systems just make sure "blurb" is on your path, then simply run "blurb". On Windows the recommended method is "python3 -m blurb". When you run blurb, it'll guide you through creating a news entry. It'll pop open an editor window on a template. Just modify the template as needed, write your news entry at the bottom, and save and exit. blurb will write out your news entry as a uniquely-named file in Misc/NEWS.d--and even stage it for you in "git"! If for some reason you want to create news entries by hand, or if you just want more information, please see the Dev Guide: https://devguide.python.org/committing/#what-s-new-and-news-entries and the documentation for blurb on PyPI: https://pypi.org/project/blurb/ The migration to Misc/NEWS.d and blurb has a few other implications: 1. Existing pending PRs or patches with Misc/NEWS entries will need to be updated to generate the entry with blurb. (Again, there really shouldn't /be/ any by this point.) 2. If you want to read a branch's NEWS entries in a convenient format, simply use "blurb merge" to produce a temporary NEWS file. (But don't check it in!) See the blurb documentation. 3. As part of the release process, release managers now use blurb to merge all the individual NEWS.d/next files into a single NEWS.d file for that version. They'll also build a traditional monolithic Misc/NEWS included in the release's source tarball (but this won't get checked in). 4. If you're building 3.x docs from a cpython git repo, you'll now need to have blurb installed. You can use the "make venv" recipe in Doc/Makefile to create a python3 venv with blurb and sphinx. Happy blurbing! /arry * All except 3.3. Ned Deily has taken over as release manager of 3.3, and he thinks we shouldn't bother with blurbifying that branch--it'll reach end-of-life in mere weeks, and we're only going to make one more release of it, and it gets very little work done these days. p.s. Thanks to Ned Deily who originally wrote this email, which I hacked up and sent.

1 0

PyCharm open source license
by Paul Moore 02 Sep '17

02 Sep '17

I've been trying out PyCharm recently, and looking through the archives here I see that some time back JetBrains provided us with a free open source license. Is that still running? And if so, how do I go about getting a copy? Thanks, Paul

3 2

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-committers September 2017