supporting python2 and python3 in kdevelop

[Sven Brauch]

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 
involve.
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. [1]

> 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,
Sven

_________
[1] 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.