supporting python2 and python3 in kdevelop
svenbrauch at googlemail.com
Tue Nov 5 00:23:41 UTC 2013
On Tuesday 05 November 2013 00:50:11 Milian Wolff wrote:
> It's just more work. (stable + master) x 2, i.e. twice the work ;-)
Well, if I compare the at most maybe 6 or 8 more releases I will do for
python2 to the amount of work it would be to merge this into one repository in
a way it actually works, and then *unmerging* it again in three years, I will
happily choose creating the tarballs ;)
Not even talking about the maintenance burden having it in one repo would
If I use separate branches, I can just maintain py2 as a legacy option and
drop it any time I want without effort. I can also at any time kind of
feature-freeze py2 and just backport necessary fixes, which will hopefully
limit the amount of releases to one per kdevelop cycle. 
> If you can merge changes, then you could also reuse code, no?
Yes, of course most of the code is the same. But still -- python 3 is
different from python 2 in so many places. It has different semantics, a
different way to retrieve string data from the parser, different (not just
more! different) AST classes and thus a different AST visitor...
It's not like you could just disable some features in python 2 mode.
Especially the different visitor pattern will imo make it very painful to use
the same source code for e.g. the declaration builder in both versions. I will
end up having different versions of AST nodes, e.g. function arguments --
there would be a Python2ArgumentsAst and a Python3ArgumentsAst (with quite
disjoint properties) and depending on which is populated the
AstDefaultVisitor, the DeclarationBuilder, the ContextBuilder and the
ExpressionVisitor would need to behave differently. And you know the code,
it's not the cleanest code ever written -- littering it with if(python3)'s
every two lines would kill it imo.
Plus re-using any code will always come at the cost of having the fork in the
py3 repo, which I don't want.
> As I said on IRC, it's another kcm plugin, similar to e.g. what I added in
> the projectfilter.
Yeah that sounds cool, I'll do that.
Thanks and greetings,
 I'm coming from kde-telepathy, there we have like 17 (no exaggeration)
repos which need to be released each time, so compared to that 2 sounds fine
Looking at it like this, kdev-php and kdev-php-docs is the same burden like
py2 and py3.
More information about the KDevelop-devel