1 |
On Tue, 2013-05-21 at 12:33 +0200, Dmitry Selyutin wrote: |
2 |
> Hello everyone! |
3 |
> |
4 |
> Since I'm going to reimplement catalyst in GSoC, I'd like to tell my |
5 |
> opinion if it has some weight. :-) |
6 |
> Some years have passed since Python 3 was created, and nowadays I |
7 |
> think it is stable enough to select it. I'd rather thought about |
8 |
> Python 2 compatibility than Python 3, since it seems to become a |
9 |
> standart soon. To cut a long story short, I'd rather oriented to |
10 |
> Python 3 than Python 2, though I prefer to use Python 2 nowadays. Of |
11 |
> course compatibility will be one of main aims, but I see some benefit |
12 |
> if we will choose Python 3 rather than Python 2, though users may |
13 |
> successfully use catalyst with Python 2 in the future. It's just a |
14 |
> proposal, so I'd like to hear your opinions. If you don't agree, we |
15 |
> may rather think about Python 2. |
16 |
|
17 |
Dmitry, It's not that I don't want it to be python3 compatible as an |
18 |
afterthought. For the same reason as i told you already. Catalyst is a |
19 |
python2 application and is working code. It is better to fix all the |
20 |
poor areas of the code first before migrating to python3. Also, that |
21 |
will fix some of the compatibility issues on it's own. That way the |
22 |
changes can be properly tested. Changing the code to py3 will bring |
23 |
enough bugs into the system on it's own. It is far better to fix the |
24 |
poor code first. |
25 |
|
26 |
> Even more, I'd like to avoid some generators and provide this support |
27 |
> manually: I've always hated generators, especially code generators |
28 |
> (and GUI ones). |
29 |
> |
30 |
> What do you think about it? |
31 |
|
32 |
Catalyst should not need to have 2to3 run on it's codebase in the ebuild |
33 |
to be py3 compatible. python2.6 and up are mostly py3 compatible |
34 |
already. Catalyst does not do anything wild that should need porting |
35 |
between versions. There are also a few tricks that can be done to |
36 |
simplify compatibility without the need for conversion runs. |
37 |
|
38 |
|
39 |
|
40 |
-- |
41 |
Brian Dolbec <dolsen@g.o> |