On 2018-07-22 01:14, Guido van Rossum wrote:
> Jeroen was asked to provide benchmarks
> but only provided them for Python 2. The reasoning that not much has
> changed that could affect the benchmarks feels a bit optimistic, that’s all.
The micro-benchmarks showed a clear difference on Python 3.8 (git
master) between tp_call and optimized call paths.
The application benchmark on Python 2.7.15 shows that the difference
between tp_call and optimized call paths matters in real applications.
I agree that this isn't 100% bullet-proof evidence, but at least it's a
strong indication that it might be worth it to start discussing the
On 2018-07-21 19:07, INADA Naoki wrote:
> Good job. But I already +1 for adding support for extension callable type.
> Do you think this benchmark can be optimized more in future optimization
> which is possible by PEP 580, but not 576?
I should clarify that the benchmark did not involve an implementation of
PEP 576 or PEP 580. It simply shows what kind of regressions one gets
when *not* implementing something like those PEPs.
So this can't be used to compare PEP 576 versus PEP 580. I still think
that PEP 576 would slow down bound method calls but without a reference
implementation, I can only guess. (I know that PEP 576 claims a
reference implementation but it doesn't correspond to the PEP. I'm
basing myself on the text of PEP 576, not the "reference implementation".)
> Do you mean you backport LOAD_METHOD and fastcall to Python 2.7
> for benchmarking?
No, I did not. This is just benchmarking the difference between tp_call
and more specialized call functions (In Python 2.7, that is
While contributing to pyannotate, I became familiar enough with 2to3
fixers to be able to convert Python 2 style annotations to Python 3.
Is it something that would be interesting to put into python 2to3 ? If
so I would propose a PR for this.
It seems like my latest status of Python CIs was already one year ago!
Since last year, Zachary Ware (with the help of others, but I forgot
names, sorry!) migrated our buildbot server from buildbot 0.8 (Python
2.7) to buildbot 0.9 (Python 3.4). The new buildbot version has a very
different web UI:
It took me time to get used to it, but now I prefer the new UI
especially to see the result of a single build. The page loads faster
and it's easier to access data. I also like the readable list of all
The buildbot "warnings" step now contains test failures and test
errors for a quick overview of bugs. Example:
FAIL: test_threads (test.test_gdb.PyBtTests)
Re-running failed tests in verbose mode
Re-running test 'test_gdb' in verbose mode
FAIL: test_threads (test.test_gdb.PyBtTests)
I also modified libregrtest (our test runner: python3 -m test) to
display a better tests summary at the end, especially when there is a
least one failure. Truncated example:
== Tests result: FAILURE then SUCCESS ==
378 tests OK.
10 slowest tests:
- test_multiprocessing_spawn: 1 min 57 sec
- test_concurrent_futures: 1 min 36 sec
- test_nntplib: 30 sec 275 ms
28 tests skipped:
1 re-run test:
Total duration: 4 min 59 sec
Tests result: FAILURE then SUCCESS
"FAILURE then SUCCESS" means that at least one test failed, but then
all re-run tests succeeded. "1 re-run test: test_threading" is the
list of tests that failed previously. That's also a new feature.
Last May, we worked hard to fix many random test failures on all CIs
before Python 3.7 final release. Today, the number of tests which fail
randomly is *very* low. Since the the beginning of the year, I fixed
bugs in more than 35 test files. The most complex issues were in
multiprocessing tests: the most common random failures should now be
Many memory and reference leaks have been fixed. I also started to fix
leaks of Windows handles:
I added new keys to test.pythoninfo: Py_DEBUG, C compiler version,
gdbm version, memory allocator, etc.
The test.bisect tool has been optimized to be usable on test_asyncio,
one of the test which has the most test cases and methods.
I spent a lot of time to fix each test failure even when a test only
failed once on one specific CI on a specific pull request. I increased
many timeouts to make fragile tests more "reliable" (reduce the risk
of failures on slow buildbots). Some timeouts are just too strict for
no good reason.
Python CIs are not perfect, but random failures should now be more rare.
Mailing list for email notifications when a buildbot fails. That's my
main source to detect regressions and tests which fail randomly:
Travis CI build history:
AppVeyor build history:
My notes on Python CIs:
Thanks Zachary Ware for maintaining our buildbot servers, thanks Pablo
Galindo Salgado who helped me to triage buildbot failures (on the
buildbot-status mailing list), thanks all other developers who helped
me to fix random test failures and make our test suite more stable!
one of our Python projects calls for pretty heavy, low-level optimizations.
We went down the rabbit hole and determined that having access to
PyList_GET_ITEM(list), PyInt_AS_LONG(int) and PyDict_GetItem(dict, unicode)
on Python objects **outside of GIL** might be a good-enough solution. The
Python objects in question are guaranteed to live and not be mutated
externally in any way. They're "frozen" and read-only.
Under what conditions is it OK to call these 3 functions on such objects?
More generally, what is the CPython 2.7/3.5 contract regarding (lack of)
object mutation, and the need for reference counting and synchronization
Which C API functions are safe to call on "const" objects?
Obviously releasing GIL and then calling C API is hacky, but from initial
experiments, it seems to work (see
But I'm wondering if there's a more formal contract around this behaviour.
Recently Barry shown an example:
assert len(subdirs := list(path.iterdir())) == 0, subdirs
It looks awful to me. It looks even worse than using asserts for
validating the user input. The assert has a side effect, and it depends
on the interpreter option (-O). Even if subdirs is not used outside of
the assert *now*, it is easy to introduce an error later, and it is hard
to notice it if tests are not ran with the -O option regularly.
Does PEP 572 encourages writing such code, discourages this, or
*Hi Folks,Cc: Rebecca, pytypeThis is Adam Cataldo; I’m the engineering
manager for the Python team at Google. Rebecca Chen, our lead pytype
<https://github.com/google/pytype> contributor, and I are interested in
helping finalize PEP 484 if possible. To that end, we wanted to find out
what technical issues the PEP 484 authors feel they still need to finalize.
We also wanted to know how we can help.We have a large Python code base at
Google, and may be able to use this to help resolve current incomplete
definitions, by collecting data on how types are used. We also have a
couple ambiguities that we’d love to get closure on: - One thing we care
about in particular, given the implementation of pytype, is the detailed
definition of what goes in a .pyi file. Do folks think this makes sense to
include as part of PEP 484, or would this be better in a separate PEP? We’d
love to get your thoughts.- The relationship between unicode and
typing.Text in Python 2 has been a recurring source of confusion for our
users. Especially since we contributed
<https://github.com/python/peps/pull/302> to the current state of affairs,
we’d like to figure out how to establish clarity here.Thoughts?Thanks,Adam*