[prev in list] [next in list] [prev in thread] [next in thread]
List: kwrite-devel
Subject: Re: Switching to Python 3
From: Todd <toddrjen () gmail ! com>
Date: 2013-11-12 16:32:34
Message-ID: CAFpSVpLfRV7CxdaDes45T-ttC3ytCdZg30V44iEyKxtKazEwGw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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:
> =93link against it=94? it=92s no native library, so that wouldn=92t even =
be
> possible.
>
> but no, we don=92t hard-depend on it: it=92s just possible to load a P=E2=
t=E9
> plugin which depends on it, and embeds a =93IPython Qt Console=94 widget =
into
> Kate=92s 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=EDn 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 b=
e
>>> 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 write=
s
>> 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
>
>
[Attachment #5 (text/html)]
<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 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 class="h5">
<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 class="im">_______________________________________________<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">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>
_______________________________________________
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