1 |
On Sat, Feb 24, 2018 at 2:57 AM, Michał Górny <mgorny@g.o> wrote: |
2 |
> W dniu pią, 23.02.2018 o godzinie 19∶58 -0700, użytkownik Daniel Robbins |
3 |
> napisał: |
4 |
>> Hi there, |
5 |
>> |
6 |
>> Zac Medico and I would like to discuss the following at the next council |
7 |
>> meeting: moving Portage to support only python3.6+. One of the primary |
8 |
>> benefits of this change is that it will allow us to use python's native |
9 |
>> async implementation as we look to make Portage faster at a critical time |
10 |
>> when we are looking to improve Portage performance. As we approach the |
11 |
>> stabilization of python3.6 in Gentoo, it seems like a good time to discuss |
12 |
>> the process of jettisoning 2.7 support and standardizing on 3.6 for Portage. |
13 |
>> |
14 |
>> Right now, a custom 'asyncio-like' set of classes is used for async in |
15 |
>> Portage. This limits interoperability with other async-friendly python |
16 |
>> modules and produces additional maintenance overhead for the project. |
17 |
>> |
18 |
>> Maybe even more importantly, 3.6+ compatibility also gives us the ability |
19 |
>> to use many other new language features and reduce the maintenance overhead |
20 |
>> of having 2.7 compatibility for the extensive Portage code-base. We expect |
21 |
>> that this will improve the velocity of Portage development, provide |
22 |
>> opportunities to improve Portage functionality and also allow us clean up a |
23 |
>> lot of unnecessarily complex code (and eliminate code) that is there only |
24 |
>> to ensure compatibility with 2.7. |
25 |
>> |
26 |
> |
27 |
> This is Portage's team decision. The Council has already voted on for |
28 |
> how long upgrade path needs to provided (that was 2 years, I think) |
29 |
> and what Portage developers decide beyond that is up to them. |
30 |
> |
31 |
> I personally don't have anything against removing support for Python 2 |
32 |
> (though I think many users would do). However, I wouldn't go up to 3.6+ |
33 |
> at once, especially if 3.5 is the current version we are using. Even if |
34 |
> we switch the default, I think it'd be reasonable to provide a lengthy |
35 |
> grace period not to make upgrading Portage PITA. |
36 |
> |
37 |
|
38 |
I am a stain upon this mailing list and my opinion is of no |
39 |
consequence, but I think moving directly to 3.6 would be the best |
40 |
option. Python 3.5 is a very strange situation and has some half |
41 |
finished features despite being a full release. It is very likely the |
42 |
release of 3.6 was rushed to fix some of what was "wrong" in 3.5 |
43 |
(mainly missing async features, but there are many).[1] These new |
44 |
features are useful enough that they will likely outweigh any |
45 |
additional work involved in adopting 3.6. |
46 |
|
47 |
Python 2.7 will still be necessary for some hardened utilities, from memory. |
48 |
|
49 |
Cheers, |
50 |
R0b0t1 |
51 |
|
52 |
|
53 |
[1]: https://docs.python.org/3/whatsnew/3.6.html |