[prev in list] [next in list] [prev in thread] [next in thread]
List: kwrite-devel
Subject: Re: Switching to Python 3
From: "Philipp A." <flying-sheep () web ! de>
Date: 2013-11-12 16:41:05
Message-ID: CAN8d9gniX-S97hD24TQnG0yPH-Qb_ap0xyXrkpVwWDo=yC75YA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
no, we can't embed it if it's not the same python version (and the same
PyQt version)
we basically do (i made the API up, but that's about how it is done):
ipython = IPythonQtConsoleWidget()
toolview = kate.createToolView('IPython Console', kate.ToolView.BOTTOM_AREA)
toolview.setContainedWidget(ipython)
2013/11/12 Todd <toddrjen@gmail.com>
> 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 or
> 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 difficult
> 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. <flying-sheep@web.de> wrote:
>
>> "link against it"? it's no native library, so that wouldn't even be
>> possible.
>>
>> but no, we don't hard-depend on it: it's just possible to load a Pâté
>> plugin which depends on it, and embeds a "IPython Qt Console" widget into
>> Kate's bottom Toolview area. Like this <http://i.imgur.com/LEnwhDp.png>
>>
>>
>> 2013/11/12 Todd <toddrjen@gmail.com>
>>
>>> On Mon, Nov 11, 2013 at 5:57 PM, Sven Brauch <svenbrauch@googlemail.com
>>> > wrote:
>>>
>>>> On Monday 11 November 2013 12:55:06 J. Pablo Martín 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 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
>>>> 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 against
>>>> 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 writes
>>> 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
>
>
[Attachment #5 (text/html)]
<div dir="ltr"><div>no, we can't embed it if it's not the same python version (and \
the same PyQt version)<br><br></div><div>we basically do (i made the API up, but \
that's about how it is done):<br><br></div><div>ipython = \
IPythonQtConsoleWidget()<br> </div><div>toolview = kate.createToolView('IPython \
Console', kate.ToolView.BOTTOM_AREA)<br><br></div><div>toolview.setContainedWidget(ipython)<br></div></div><div \
class="gmail_extra"><br><br><div class="gmail_quote"> 2013/11/12 Todd <span \
dir="ltr"><<a href="mailto:toddrjen@gmail.com" \
target="_blank">toddrjen@gmail.com</a>></span><br><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div \
dir="ltr"><div class="gmail_extra"><div class="gmail_quote">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 or 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 difficult 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).<br>
</div><div><div class="h5"><div class="gmail_quote"><br>On Tue, Nov 12, 2013 at 2:12 \
PM, Philipp A. <span dir="ltr"><<a href="mailto:flying-sheep@web.de" \
target="_blank">flying-sheep@web.de</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">
<div dir="ltr"><div><p style="margin:1.2em 0px!important">"link against it"? it's no \
native library, so that wouldn't even be possible.</p> <p style="margin:1.2em \
0px!important">but no, we don't hard-depend on it: it's just possible to load a \
Pâté plugin which depends on it, and embeds a "IPython Qt Console" widget into \
Kate's bottom Toolview area. Like <a href="http://i.imgur.com/LEnwhDp.png" \
target="_blank">this</a></p>
</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/11/12 Todd \
<span dir="ltr"><<a href="mailto:toddrjen@gmail.com" \
target="_blank">toddrjen@gmail.com</a>></span><br><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div>
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>On Mon, Nov 11, \
2013 at 5:57 PM, Sven Brauch <span dir="ltr"><<a \
href="mailto:svenbrauch@googlemail.com" \
target="_blank">svenbrauch@googlemail.com</a>></span> wrote:<br>
</div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"><div>On Monday 11 November 2013 12:55:06 J. Pablo \
Martín Cobos wrote:<br> > Because the pep8,<br>
> pyflakes and parse syntax checker will report errors, because the syntax is<br>
> different in python 2 and python 3.<br>
</div>Okay, I looked a bit more and this is indeed a valid concern.<br>
<br>
The problem is that some of the plugins (pep8 and the ipython console, at<br>
least) call straight into the mentioned tools and do something with them, and<br>
the tools (e.g. ipython console) will be the version of the language kate was<br>
linked against.<br>
<br>
For most of the tools the solution is imo easy: e.g. pep8 should just be<br>
called as a program and the output should be parsed. It's very simple ... \
yes,<br> not as elegant, but who cares.<br>
<br>
For ipython however it's less obvious ... I'm not sure how the problem \
could<br> be solved here. The only solution I found is based on creating a widget \
and<br> then letting a new process draw into the widget, but that sort of sucks<br>
(especially I'm not sure how portable it is). That's more work and more \
bad<br> than just keeping the current situation, so not worth it imo.<br>
<br>
What I said earlier in the thread was referring only to what language should<br>
be available for writing the plugins, assuming plugins which are just doing<br>
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 against \
both<br> libs" is indeed the best \
solution.<br></blockquote><div><br></div></div><div>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 writes to? <br>
</div></div></div></div>
<br></div></div><div>_______________________________________________<br>
KWrite-Devel mailing list<br>
<a href="mailto:KWrite-Devel@kde.org" target="_blank">KWrite-Devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kwrite-devel" \
target="_blank">https://mail.kde.org/mailman/listinfo/kwrite-devel</a><br> \
<br></div></blockquote></div><br></div> \
<br>_______________________________________________<br> KWrite-Devel mailing list<br>
<a href="mailto:KWrite-Devel@kde.org" target="_blank">KWrite-Devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kwrite-devel" \
target="_blank">https://mail.kde.org/mailman/listinfo/kwrite-devel</a><br> \
<br></blockquote></div><br></div></div></div></div> \
<br>_______________________________________________<br> KWrite-Devel mailing list<br>
<a href="mailto:KWrite-Devel@kde.org">KWrite-Devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kwrite-devel" \
target="_blank">https://mail.kde.org/mailman/listinfo/kwrite-devel</a><br> \
<br></blockquote></div><br></div>
_______________________________________________
KWrite-Devel mailing list
KWrite-Devel@kde.org
https://mail.kde.org/mailman/listinfo/kwrite-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic