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
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/
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
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 -- []
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.
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
