1 |
Hi there, |
2 |
|
3 |
Zac Medico and I would like to discuss the following at the next council |
4 |
meeting: moving Portage to support only python3.6+. One of the primary |
5 |
benefits of this change is that it will allow us to use python's native |
6 |
async implementation as we look to make Portage faster at a critical time |
7 |
when we are looking to improve Portage performance. As we approach the |
8 |
stabilization of python3.6 in Gentoo, it seems like a good time to discuss |
9 |
the process of jettisoning 2.7 support and standardizing on 3.6 for Portage. |
10 |
|
11 |
Right now, a custom 'asyncio-like' set of classes is used for async in |
12 |
Portage. This limits interoperability with other async-friendly python |
13 |
modules and produces additional maintenance overhead for the project. |
14 |
|
15 |
Maybe even more importantly, 3.6+ compatibility also gives us the ability |
16 |
to use many other new language features and reduce the maintenance overhead |
17 |
of having 2.7 compatibility for the extensive Portage code-base. We expect |
18 |
that this will improve the velocity of Portage development, provide |
19 |
opportunities to improve Portage functionality and also allow us clean up a |
20 |
lot of unnecessarily complex code (and eliminate code) that is there only |
21 |
to ensure compatibility with 2.7. |
22 |
|
23 |
Best, |
24 |
|
25 |
Daniel |