On 05/21/2013 10:33 AM, Brian Dolbec wrote:
On Tue, 2013-05-21 at 12:33 +0200, Dmitry Selyutin wrote:
Hello everyone!
Since I'm going to reimplement catalyst in GSoC, I'd like to tell my
opinion if it has some weight. :-)
Some years have passed since Python 3 was created, and nowadays I
think it is stable enough to select it. I'd rather thought about
Python 2 compatibility than Python 3, since it seems to become a
standart soon. To cut a long story short, I'd rather oriented to
Python 3 than Python 2, though I prefer to use Python 2 nowadays. Of
course compatibility will be one of main aims, but I see some benefit
if we will choose Python 3 rather than Python 2, though users may
successfully use catalyst with Python 2 in the future. It's just a
proposal, so I'd like to hear your opinions. If you don't agree, we
may rather think about Python 2.
Dmitry, It's not that I don't want it to be python3 compatible as an
afterthought. For the same reason as i told you already. Catalyst is a
python2 application and is working code. It is better to fix all the
poor areas of the code first before migrating to python3. Also, that
will fix some of the compatibility issues on it's own. That way the
changes can be properly tested. Changing the code to py3 will bring
enough bugs into the system on it's own. It is far better to fix the
poor code first.
Even more, I'd like to avoid some generators and provide this support
manually: I've always hated generators, especially code generators
(and GUI ones).
What do you think about it?
Catalyst should not need to have 2to3 run on it's codebase in the ebuild
to be py3 compatible. python2.6 and up are mostly py3 compatible
already. Catalyst does not do anything wild that should need porting
between versions. There are also a few tricks that can be done to
simplify compatibility without the need for conversion runs.
Thank you all for the advice and feedback. Things like "don't base any
real work on the master branch at
git://git.overlays.gentoo.org/proj/catalyst.git" are exactly what I was
hoping to hear.
Some other thoughts:
I wouldn't call what I'm proposing to do "refactoring". I've _used_
catalyst for quite a while but only looked at its code a few days ago.
The extent of my changes would be "make it run on Python 3 and update
some parts of the code to use newer/cleaner Python idioms".
Almost all of the bugs introduced in 2to3 conversion will be bytes/str
related, and it's easy enough to decode() text that is read from a
subprocess. Everything should be valid UTF-8, so there won't be any
unpleasant character encoding issues.
It's likely that I'm wrong about this, but I don't think that there is
much (any?) benefit to supporting Python 2 and Python 3 with the same
code base. I have added 2to3 conversion to a few setup.py files, but
these were in Python packages that still had to support Python 2 on
multiple distributions. Catalyst is fundamentally a Gentoo
_application_, and the implementation details don't really matter as
long as it runs on current Gentoo systems. From my own experience as a
user, I run the catalyst executable and I don't particularly care
whether it's implemented in C, Java, Haskell, Python, INTERCAL, etc. I
only care that I can 'emerge catalyst', make some tweaks to its files in
/etc, and run 'catalyst'.
Since Python 3.2+ is available on all current Gentoo systems and will be
from now on, I don't think there's anything to lose by doing a one-shot
conversion and changing relevant hashbang lines to "#!/usr/bin/env python3".
(Brian: you may want to change
http://dev.gentoo.org/~dolsen/catalyst/HEAD to contain "ref:
refs/heads/rewrite" :) )
Thanks,
MMR...
