Righ= t, that was my point.=A0 With something like iPython, it shouldn't be m= uch more difficult to support both python 2 and python 3 than just one or t= he other, you just need either the user or the distro to set the right comm= and to execute.=A0 Supporting two versions wouldn't be any more difficu= lt than just allowing two commands to be set (which for something like iPyt= hon, which has a lot of flexibility with different profiles, might be a goo= d thing even without python 2 support).

On Tue, Nov 12, 2013 at 2:12 PM, Phili= pp A. <flying-sheep@web.de> wrote:

=93link again= st it=94? it=92s no native library, so that wouldn=92t even be possible.
but no, we don=92t hard-depend on i= t: it=92s just possible to load a P=E2t=E9 plugin which depends on it, and = embeds a =93IPython Qt Console=94 widget into Kate=92s bottom Toolview area= . Like this

2= 013/11/12 Todd <toddrjen@gmail.com>

On Mon, Nov 11, 2013 at 5:57 PM, Sven Brauch <svenbrauch@googlema= il.com> wrote:

On Monday 11 November 2013 1= 2:55:06 J. Pablo Mart=EDn Cobos wrote:
> Because the pep8,
> pyflakes and parse syntax checker will report errors, because the synt= ax is
> different in python 2 and python 3.

Okay, I looked a bit more and this is indeed a valid concern.

The problem is that some of the plugins (pep8 and the ipython console, at least) call straight into the mentioned tools and do something with them, a= nd
the tools (e.g. ipython console) will be the version of the language kate w= as
linked against.

For most of the tools the solution is imo easy: e.g. pep8 should just be called as a program and the output should be parsed. It's very simple .= .. yes,
not as elegant, but who cares.

For ipython however it's less obvious ... I'm not sure how the prob= lem could
be solved here. The only solution I found is based on creating a widget and=
then letting a new process draw into the widget, but that sort of sucks
(especially I'm not sure how portable it is). That's more work and = more bad
than just keeping the current situation, so not worth it imo.

What I said earlier in the thread was referring only to what language shoul= d
be available for writing the plugins, assuming plugins which are just doing=
stuff but not actually _importing python tools and using them in-process_.<= br> For this issue, I'm not sure how to proceed. Possibly the "link ag= ainst both
libs" is indeed the best solution.

Why, exactly, do we need to link against iPython?=A0 Why can't t= here just be a console that launches iPython, or an html canvas that iPytho= n writes to? =A0

_________________________________________= ______
KWrite-Devel mailing list
KWrite-Devel@kde.= org
https://mail.kde.org/mailman/listinfo/kwrite-devel

_______________________________________________
KWrite-Devel mailing list
KWrite-Devel@kde.org
https://mail.kde.org/mailman/listinfo/kwrite-devel