1 |
Hi, |
2 |
|
3 |
I think I've made a mistake by stabilizing PyPy(3), and I would like to |
4 |
drop it back to ~arch (and stable-mask the relevant flags). |
5 |
|
6 |
Roughly, there are 4 problems with it: |
7 |
|
8 |
1. The current stable (both Gentoo and upstream) is PyPy3.6 that is |
9 |
equivalent to CPython 3.6. Yes, the one we removed already. People |
10 |
using this version are already hitting issues because of upstreams |
11 |
dropping py3.6 support or us failing to provide proper compatibility. |
12 |
|
13 |
2. The next branch, PyPy3.7 is still in alpha state upstream. It has |
14 |
a few major bugs, e.g. the regex engine is sometimes slightly broken. |
15 |
The stdlib tests are mostly broken (compared to moderately broken |
16 |
in 3.6). |
17 |
|
18 |
3. To the best of my knowledge, there's no work hapenning to have |
19 |
PyPy3.8, so it will keep being behind CPython. |
20 |
|
21 |
4. PyPy upstream doesn't merge CPython stdlib changes timely, nor takes |
22 |
care of vulnerabilities inherited from CPython. |
23 |
|
24 |
5. PyPy3 doesn't give the same ABI stability guarantees as CPython, |
25 |
and our choice not to slot between PyPy3 versions doesn't help (and it's |
26 |
not worth changing considering all the other points). Upgrading PyPy3 |
27 |
involves intermittent breakage, and people using it with Portage (which |
28 |
is my fault) experience fatal breakage. |
29 |
|
30 |
|
31 |
Honestly, I've tried to improve PyPy in the past but I don't really have |
32 |
time or motivation to do this continuously. PyPy is an interesting |
33 |
project, and it has its isolated uses. However, I don't think it's |
34 |
ready as a general-purpose Python interpreter for production |
35 |
environments. |
36 |
|
37 |
I don't really want to remove it entirely or revert all the work we've |
38 |
put into testing packages with it -- but I think we should move it to |
39 |
~arch at the very least. |
40 |
|
41 |
WDYT? |
42 |
|
43 |
-- |
44 |
Best regards, |
45 |
Michał Górny |