[Python-projects] Py3k port

[Sylvain Thénault]

On 01 septembre 11:35, Emile Anclin wrote:
> On Monday 16 August 2010 14:08:25 Tshepang Lekhonkhobe wrote:
> > On Thu, Aug 12, 2010 at 23:03, Tshepang Lekhonkhobe <tshepang at gmail.com> 
> wrote:
> > > Hi,
> > >
> > > So where do I start if I want Pylint ported to Py3k? Is there a
> > > branch somewhere?
> >
> > Thanks for the great responses. It's a little confusing though, so can
> > you guys create some page (wiki?) somewhere on your site on what
> > actually needs to be done by a wannabe like me (with a link tothe
> > ticket: http://www.logilab.org/ticket/19645).
> 
> I had some thoughts on the py3k port:
> 
> * as I understand it, pylint for python 2.X will only run against 2.X
> and pylint3 will have to run against 3.X: the reason is that the _ast 
> module used for astng will parse the code as 2.X / 3.X, and throws 
> SyntaxErrors if the code is not acceptable for the running python 
> version.

right
 
> * imho, the py3k branch in logilab-common is not very usefull: it is just 
> passing 2to3 on the whole package. Following the python doc,
> http://docs.python.org/release/3.0.1/whatsnew/3.0.html#porting-to-python-3-0
> we should not go along this way.

py3k branch of logilab.common was a try out that should eventually be
discarded. At least for lgc, I would like a solution where running 2to3 
is enough.

> I'll try to propose a plan corresponding to what is explained on python 
> doc:
> 
> 1) make logilab-common run on py3k (i.e. make the tests work).
>    this should also make pytest run on python3.X
>    I believe we need that to run the tests on astng and pylint;

no, as I said I don't want to bother with pytest/testlib in the py3k port
since those both module are a dead end. And they represent 25% of lgc's code...
 
> 2) astng:
>    
>    a) we will have some work to make the old tests pass, related to this:
>  
>    b) quote my mail from Mon Apr 12 10:58:24 CEST 2010:
> """
> we will have to parse new kind of nodes (Nonlocal, Dict/SetGenerator, 
> Starred (at least for extended literal unpacking), SetComp etc. hence a 
> lot of new 'visit_%' methods in astng
> """
> 
>    c) deal with 'print' as a function and the other modifications

I don't think we need anything special to deal with print as a function.
It will simply be treated as other functions.

>    *) there is actually not that much stuff concerning python <=2.4,
>   just one module, hence not much work to save...
 
though things could be fairly simplified by dropping that compiler/_ast
duality.

> 3) pylint; make tests pass with py3k, write new visit_* methods and 
> test...

there should be no need for new visit_* methods, beside if we want
new functionnalities. 
 
> Fully Automated conversion will not work. We have more than syntactic 
> changes to do: we have different trees with new nodes, nodes that 
> disappear...

We already deal with this kind of pb with different python versions, so
that should not be the show stopper.

-- 
Sylvain Thénault                               LOGILAB, Paris (France)
Formations Python, Debian, Méth. Agiles: http://www.logilab.fr/formations
Développement logiciel sur mesure:       http://www.logilab.fr/services
CubicWeb, the semantic web framework:    http://www.cubicweb.org