It is full of great people and minds, and interacting with people at
conferences is always nice and stimulating. But one of my favorite things is
that over time, after many conferences, talks, pull requests and beers, the
personal relationship with some of them strengthen and they become friends.
I am fortunate enough that two of them, Łukasz Langa and Hood Chatham, accepted my
invitation to join me in Cervinia, at the border between Italian and Swiss Alps,
for a week of hacking, winter sports and going literally over the clouds. This
is a brief summary of what we did during our time together.
The organizers of the summit will soon publish a full report about the event
(edit: now available
here),
but for the HPy-specific
part,
we got generally good feedback. Someone has a few concerns that if CPython is
to change the API, HPy might not be going far enough. Others said that Python
shouldn't wait for the "perfect" API if HPy can be the "good" one that helps it
evolve.
Everyone was open to have HPy-compatible wheels on PyPI, once the HPy
Universal ABI stays relatively stable. Many people suggested that we should
really write a PEP to propose HPy as a "semi-official" API for Python.
HPy has been around for a while now. The initial discussion started during
EuroPython 2019, in the good old times when we could still go to conferences
and have real-life meetings. Since then, HPy progressed a lot from the
point of view of the actual code, but we have been a bit too silent
w.r.t. communicating what we are doing to the external world and to the broader
Python community. Hopefully, now that this blog is online we will do a better
job at periodically communicating the status of HPy, so make sure to
subscribe to the RSS feed.
Recently Antonio, Armin and Ronan had a small internal sprint in the beautiful
city of Gdańsk to kick-off the development of HPy. Here is a brief report of
what was accomplished during the sprint.
Recently I have merged the gc-disable branch, introducing a couple of features
which are useful when you need to respond to certain events with the lowest
possible latency. This work has been kindly sponsored by Gambit Research
(which, by the way, is a very cool and geeky place where to work, in case you
are interested). Note also that this is a very specialized use case, so these
features might not be useful for the average PyPy user, unless you have the
same problems as described here.
If you install any Cython-based module in PyPy 6.0.0, it is very likely that you get a warning like this:
>>>> import numpy
/data/extra/pypy/6.0.0/site-packages/numpy/random/__init__.py:99: UserWarning: __builtin__.type size changed, may indicate binary incompatibility. Expected 888, got 408
from .mtrand import *
The TL;DR version is: the warning is a false alarm, and you can hide it by doing:
$ pypy -m pip install pypy-fix-cython-warning
The package does not contain any module, only a .pth file which installs a warning filter at startup.
Technical details
This happens because whenever Cython compiles a pyx file, it generates C code which does a sanity check on the C size of PyType_Type. PyPy versions up to 5.10 are buggy and report the incorrect size, so Cython includes a workaround to compare it with the incorrect value, when on PyPy.
PyPy 6 fixed the bug and now PyType_Type reports the correct size; however, Cython still tries to compare it with the old, buggy value, so it (wrongly) emits the warning.
Cython 0.28.2 includes a fix for it, so that C files generated by it no longer emit the warning. However, most packages are distributed with pre-cythonized C files. For example, numpy-1.14.2.zip include C files which were generated by Cython 0.26.1: if you compile it you still get the warning, even if you locally installed a newer version of Cython.
I often hear people who are happy because PyPy makes their code 2 times faster
or so. Here is a short personal story which shows PyPy can go well beyond
that.
