kdev-python move to extragear -- once more

[Sven Brauch]

Hi,

>> And the rest of the Python library API, like the stuff in Python/* and
>> Object/*?
> Those aren't being used.  Only the parser is used.
I'm sorry, I forgot that the AST stuff is in Python/ (it has been a
while). So, the ast-related stuff from Python/ is being used too.
Thus, diffing Parser/ was not correct, I apologize. Still, the point
that only few of the code paths python has are actually used by the
plugin remains valid, since only the "parse string to ast" step is
being done, but neither "compile ast to bytecode" nor "execute
bytecode" step, which account for large parts of python's complexity.

> Afaik: That is semantically analized to extract information like
> documentation, code completion information etc. pp. Comparable to
> phpfunctions.php in the kdev-php plugin.
> Sven, can you confirm that?
No, they are not being analyzed, it's just difficult to rip them out
of python so they're still there.

> I thought the big concern here is security? Any "mundane" bugs like leaks etc.
> pp. don't need to be any of your concern here, or? I mean assuming Sven
> updates the checkout regularily these will be fixed eventually. I'd simply see
> it as a bug in kdev-python. And comparing that to the amount of bugs you'd get
> by writing your own python parser it is probably a good pick.
This is the real point in my opinion, yes. Writing a custom parser
will have a much larger amount of exploitable bugs for years to come
than the python 2.7 parser currently has. Thus, I don't really get the
"security" argument. Plus, if crtical flaws should really turn up (a
situation which I still consider somewhat theoretical), I would of
course take care of merging the relevant patches.

> "people will package it" is not really an excuse for "allow broken
> ways".
But "it could potentially cause extra work for the packagers" is the
only argument against the fork I heard so far which I can agree with.
That's why I said that.

> (And WTF does it mean «I just wished you would list reasons I could
> agree with», that my reasons are valid as long as you agree with them?)
No, it just means I'm somewhat unhappy with the reasons you listed
since I don't agree with them. In other words, I'll have to accept
them as reasons why to reject the application altough I don't share
your opinion, and that's bad for me.

> Bugs, leaks, and any kind of issue don't need to "affect kdev-python" to
> be problematic.
Why? If such an issue is in a code path which is never used by
kdev-python, it doesn't matter. Which will be like, most issues,
because the whole stuff that actually compiles and runs python code is
not being used by kdev-python.
Also, memory leaks in Python? Python is like this (when executing a
non-trivial script):
  definitely lost: 0 bytes in 0 blocks
  indirectly lost: 0 bytes in 0 blocks
Plus, any leak would be free'd after the parse step anyways, which
takes like 0.3 seconds.
About bugs, what kind of bugs are you thinking of? In the worst case,
it'll just be a crash bug in kdev-python, which is entirely my
problem. Additionally, crash bugs in the python *parser* is something
that realistically doesn't exist, especially not to an extent I or
kdevelop should care about, given the amount of crash bugs we have
ourselves.

I just want to emphasize this again: During the time I'm working on
kdev-python, I will *never* be able to write a parser which is
comparably secure and bug-free to the current solution with the fork.

> Assuming you need to cherry-pick later some bugfix from python 2.7.x,
> what do you do if that backporting cannot be done because the code has
> changed in the meanwhile, and your code is still years behind?
Sorry, I'm not sure I understand what you mean -- who would do the cherry-pick?

Also, I want to repeat that I already contacted the python people, and
that it's very likely that the issue causing the patch will be
resolved upstream. Thus, with the release of python 3.4, the fork
would disappear anyways. (backporting is not possible since the patch
involves binary incompatible changes)

Best regards,
Sven

2013/3/12 Todd <toddrjen at gmail.com>:
> On Tue, Mar 12, 2013 at 10:57 AM, Pino Toscano <pino at kde.org> wrote:
>>
>> Hi,
>>
>> Alle sabato 9 marzo 2013, Sven Brauch ha scritto:
>> > considering kdev-python is only using the Parser part of python, this
>> > is actually all that has changed in the two years between 2.7.1 and
>> > 2.7.3:
>> > http://paste.kde.org/691184/
>> > As far as I can see, there's not a single change which would affect
>> > the behavior of kdev-python in any way. And I do not expect such
>> > changes to happen in further maintenance releases -- after all,
>> > they're maintenance releases for fixing bugs, and the Python 2.7
>> > *parser* code does not exactly have hundreds of bugs. And, since
>> > Python 2 is dead anyways, no non-maintenance releases are going to
>> > happen.
>>
>> And the rest of the Python library API, like the stuff in Python/* and
>> Object/*?
>
>
> Those aren't being used.  Only the parser is used.