From kwrite-devel Mon Nov 11 13:18:07 2013 From: =?ISO-8859-1?Q?J=2E_Pablo_Mart=EDn_Cobos?= Date: Mon, 11 Nov 2013 13:18:07 +0000 To: kwrite-devel Subject: Re: Switching to Python 3 Message-Id: X-MARC-Message: https://marc.info/?l=kwrite-devel&m=138418909312133 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============7673277699390898790==" --===============7673277699390898790== Content-Type: multipart/alternative; boundary=047d7b86de8211cd8804eae690d7 --047d7b86de8211cd8804eae690d7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 2013/11/11 Philipp A. > 2013/11/11 Sven Brauch > >> Why not just run those utilities as provided by the system? There's pep8= - >> python2 and pep8-python3, so you can just execute those programs and hav= e >> both >> language versions supported, no? >> >> Or does kate currently invoke them using libpython too? In that case thi= s >> should maybe be changed. >> >> Sven >> > > the tool is written using python and has a python api, so it=92s pretty > natural to just use that instead of letting the tool create python > datastructures, convert them to text, write that text to a pipe, read tha= t > text from the pipe, and parse it into python datastructures again. > > but i agree: if pep8.py can=92t be fixed to work on scripts written in th= e > version of python that it isn=92t run with, we should do that. for the sa= ke > of elegance, however, we should only use that backwards way for the other > version (i.e. use the python api to use pep8.py on python 3 files, and us= e > a shell to run python2 pep8.py and parse the output on python2 files) > > Thanks for the explication. > PS: we have quite a bunch of linters now. i think it=92s time to generate= a > common linter base class that can be subclassed. like: > > 1. BaseLinter (base class for all linters with methods to run it and > show line highlights and a method that runs it and returns a list of e= rrors) > 2. ConsoleLinter (where you have to pass a console command and if it > can use stdin or has to use a tmpfile, as well as have to override a m= ethod > to parse its output to a list of errors) > 3. JSLinter (uses my new JS framework that currently lives in jsutils > to load a JS module and pass the lintable source through it) > > i=92ll be glad to write it once my changes to jsutils get pulled and we g= ot > rid of kate.gui in favor of a better alternative. > > _______________________________________________ > KWrite-Devel mailing list > KWrite-Devel@kde.org > https://mail.kde.org/mailman/listinfo/kwrite-devel > > --047d7b86de8211cd8804eae690d7 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
2013/11/11 Philipp A. <flying-sheep@web.de>
2013/11/11 Sven Brauch <svenbrauch@googlemail.com>
Why not just run those utilities as provided by the system? There's pep= 8-
python2 and pep8-python3, so you can just execute those programs and have b= oth
language versions supported, no?

Or does kate currently invoke them using libpython too? In that case this should maybe be changed.

Sven

<= div>the tool is written using python and has a python api, so it=92s pretty= natural to just use that instead of letting the tool create python datastr= uctures, convert them to text, write that text to a pipe, read that text fr= om the pipe, and parse it into python datastructures again.


PS: we have quite a bunch of linters now. i think it=92s time = to generate a common linter base class that can be subclassed. like:
  • BaseLinter (base class for all linters with methods to run it and show line= highlights and a method that runs it and returns a list of errors)
  • ConsoleLinter (where you have to pass a console command and if it can u= se stdin or has to use a tmpfile, as well as have to override a method to p= arse its output to a list of errors)
  • JSLinter (uses my new JS frame= work that currently lives in jsutils to load a JS module and pass the linta= ble source through it)

    • i=92ll be glad to write it once my changes to jsutils get pulled an= d we got rid of kate.gui in favor of a better alternative.


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


    --047d7b86de8211cd8804eae690d7-- --===============7673277699390898790== 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 --===============7673277699390898790==--