A quick update: after many months we are at the finish line. We are on
track (mixing metaphors) to release 3.7.0 (and 3.6.6) this week on
2018-06-27. Since 3.7.0rc1 shipped 2 weeks ago, I am aware of only two
noteworthy regressions that have been identified and now fixed. Since
the issues for both have the potential to impact some (but small)
subsets of 3.7.0 users and the fixes for both are straightforward and
appear to be low-risk, I am planning to cherry-pick the fixes for them
into 3.7.0 final without either another release candidate cycle or
waiting for 3.7.1. There may be some doc fixes that get cherry-picked
as well. At the moment, there are no plans for any bug cherry-picks for
As you know, a new feature release is a big deal and something for all
of us to be proud of. A new feature release also has various, mostly
minor, impacts to lots of different parts of our development
infrastructure: to multiple branches of the cpython repo, to
documentation builds, to different parts of the python.org web site,
etc. You will start to see some of the changes roll out over the next 24
to 36 hours and it may take some time until everything is in place.
So please be patient until the official release announcement goes out
before reporting release-related issues. Also be advised that over the
same period, there may be a few brief periods where commit access to
various cpython branches is blocked in order to do the necessary
release engineering. If you run into this, for example when trying to
merge a PR, please try again in a few hours.
Thanks and more later!
nad(a)python.org -- 
I have a first draft implementation of PEP 580 (introducing the C call
Almost all tests pass, only test_gdb and test_pydoc fail for me. I still
have to fix those.
On 2018-06-23 03:50, Steven D'Aprano wrote:
> I think it is more important that builtin methods and Python methods
> behave the same.
This inconsistency is the *real* problem here. It's one little extra
complication to merging those classes (which was proposed in PEP 575,
576 and 579).
Currently, we have:
>>> .append == .append
However, with a Python class:
>>> class List(list):
... def append(self, x): super().append(x)
>>> List().append == List().append
In the former case, __self__ is compared using "is" and in the latter
case, it is compared using "==".
I think that comparing using "==" is the right thing to do because "is"
is really an implementation detail. Consider
>>> (10000).bit_length == (10000).bit_length
>>> (10000).bit_length == (10000+0).bit_length
I guess that's also the reason why CPython internally rarely uses "is"
there is a case in the Python API where I am not sure what to do:
If an object defines __getitem__() only but no __len__(),
then PySequence_Check() already is true and does not care.
So if I define no __len__, it simply fails. Is this intended?
I was mislead and thought this was the unlimited case, but
it seems still to be true that sequences are always finite.
Can someone please enlighten me?
Christian Tismer-Sperling :^) tismer(a)stackless.com
Software Consulting : http://www.stackless.com/
Karl-Liebknecht-Str. 121 : http://pyside.org
14482 Potsdam : GPG key -> 0xE7301150FB7BEE0E
phone +49 173 24 18 776 fax +49 (30) 700143-0023
On 2018-06-21 13:33, Ivan Pozdeev via Python-Dev wrote:
> First, tell us what problem you're solving.
There is no specific problem I want to solve here. I just noticed an
inconsistency and I wondered if it would be OK to change the
implementation of comparisons of builtin_function_or_method instances.
It's a valid question to ask even if it doesn't solve an actual problem.