From kwrite-devel Tue Nov 12 16:41:05 2013 From: "Philipp A." Date: Tue, 12 Nov 2013 16:41:05 +0000 To: kwrite-devel Subject: Re: Switching to Python 3 Message-Id: X-MARC-Message: https://marc.info/?l=kwrite-devel&m=138427447614529 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============7534120829601408298==" --===============7534120829601408298== Content-Type: multipart/alternative; boundary=089e0115f8fac8c4fb04eafd8307 --089e0115f8fac8c4fb04eafd8307 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable no, we can=E2=80=99t embed it if it=E2=80=99s not the same python version (= and the same PyQt version) we basically do (i made the API up, but that=E2=80=99s about how it is done= ): ipython =3D IPythonQtConsoleWidget() toolview =3D kate.createToolView('IPython Console', kate.ToolView.BOTTOM_AR= EA) toolview.setContainedWidget(ipython) 2013/11/12 Todd > Right, that was my point. With something like iPython, it shouldn't be > much more difficult to support both python 2 and python 3 than just one o= r > the other, you just need either the user or the distro to set the right > command to execute. Supporting two versions wouldn't be any more difficu= lt > than just allowing two commands to be set (which for something like > iPython, which has a lot of flexibility with different profiles, might be= a > good thing even without python 2 support). > > On Tue, Nov 12, 2013 at 2:12 PM, Philipp A. wrote: > >> =E2=80=9Clink against it=E2=80=9D? it=E2=80=99s no native library, so th= at wouldn=E2=80=99t even be >> possible. >> >> but no, we don=E2=80=99t hard-depend on it: it=E2=80=99s just possible t= o load a P=C3=A2t=C3=A9 >> plugin which depends on it, and embeds a =E2=80=9CIPython Qt Console=E2= =80=9D widget into >> Kate=E2=80=99s bottom Toolview area. Like this >> >> >> 2013/11/12 Todd >> >>> On Mon, Nov 11, 2013 at 5:57 PM, Sven Brauch >> > wrote: >>> >>>> On Monday 11 November 2013 12:55:06 J. Pablo Mart=C3=ADn Cobos wrote: >>>> > Because the pep8, >>>> > pyflakes and parse syntax checker will report errors, because the >>>> syntax 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, and >>>> the tools (e.g. ipython console) will be the version of the language >>>> kate was >>>> 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 problem >>>> could >>>> be solved here. The only solution I found is based on creating a widge= t >>>> and >>>> then letting a new process draw into the widget, but that sort of suck= s >>>> (especially I'm not sure how portable it is). That's more work and mor= e >>>> 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 >>>> should >>>> be available for writing the plugins, assuming plugins which are just >>>> doing >>>> stuff but not actually _importing python tools and using them >>>> in-process_. >>>> For this issue, I'm not sure how to proceed. Possibly the "link agains= t >>>> both >>>> libs" is indeed the best solution. >>>> >>> >>> Why, exactly, do we need to link against iPython? Why can't there just >>> be a console that launches iPython, or an html canvas that iPython writ= es >>> to? >>> >>> _______________________________________________ >>> 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 >> >> > > _______________________________________________ > KWrite-Devel mailing list > KWrite-Devel@kde.org > https://mail.kde.org/mailman/listinfo/kwrite-devel > > --089e0115f8fac8c4fb04eafd8307 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
no, we can=E2=80=99t embed it if it=E2=80=99s not the= same python version (and the same PyQt version)

we basic= ally do (i made the API up, but that=E2=80=99s about how it is done):
ipython =3D IPythonQtConsoleWidget()
toolview =3D kate.createToolView('IPython Console', kate= .ToolView.BOTTOM_AREA)

toolview.setContainedWidget(ipytho= n)


2013/11/12 Todd <toddrjen@gmail.com>
Righ= t, that was my point.=C2=A0 With something like iPython, it shouldn't b= e much more difficult to support both python 2 and python 3 than just one o= r the other, you just need either the user or the distro to set the right c= ommand to execute.=C2=A0 Supporting two versions wouldn't be any more d= ifficult than just allowing two commands to be set (which for something lik= e iPython, which has a lot of flexibility with different profiles, might be= a good thing even without python 2 support).

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

=E2=80=9Clink= against it=E2=80=9D? it=E2=80=99s no native library, so that wouldn=E2=80= =99t even be possible.

but no, we don=E2=80=99t hard-depen= d on it: it=E2=80=99s just possible to load a P=C3=A2t=C3=A9 plugin which d= epends on it, and embeds a =E2=80=9CIPython Qt Console=E2=80=9D widget into= Kate=E2=80=99s 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=C3=ADn 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?=C2=A0 Why can'= t there just be a console that launches iPython, or an html canvas that iPy= thon writes to? =C2=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



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


--089e0115f8fac8c4fb04eafd8307-- --===============7534120829601408298== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KWrite-Devel mailing list KWrite-Devel@kde.org https://mail.kde.org/mailman/listinfo/kwrite-devel --===============7534120829601408298==--