Compiler, ast and forwards/backwards compatibility

[Terry Reedy]

Orestis Markou wrote:
> On Tue, Oct 7, 2008 at 5:39 PM, Terry Reedy <tjreedy at udel.edu> wrote:
>> Orestis Markou wrote:
>>> Hello,
>>>
>>> I'm the developer of PySmell ( http://github.com/orestis/pysmell ), a
>>> static analysis/intellisense provider for Python. I am targeting
>>> Python 2.4 code so I'm using the compiler package.
>>>
>>> I've been toying around yesterday with the ast module in Python 2.6
>>> and it seems much more cleaner. One thing I don't understand is how
>>> should one handle backwards and forwards compatibility.
>> My impression is that the 2.6 ast package is quite different from the 2.4
>> compiler package, but I have not looked at it (in its 3.0 version) yet.  If
>> the 2.4 code you are analyzing is syntactically and sematically valid as 2.6
>> code, which I believe is usual, then of course there is no problem.  If it
>> is not, then I would not be sure.
> 
> The ast module is indeed very different from the compiler package, as
> it depends on the exact grammar definition that the interpreter is
> using, rather a re-implementation (which I understand the compiler.ast
> is).
> 
> My confusion starts with the fact that I'm not sure if all Python 2.4
> code is going to be syntactically valid 2.6 code. I guess 2.3 is valid
> 2.4 is valid 2.5, which should be valid 2.6 (but not valid 3.0) - I
> think it's the lockstep of 2.6 and 3.0 that's misleading me...

The lockstep stuff is either new stuff which does not (at least, is 
intended not to) affect old code, or changes that you have to request 
via __future__ imports.  Much 1.5 code runs fine on 2.6.

I was careful to differentiate between syntax and semantics.  I do not 
know of any 2.4 syntax that would not work in 2.6.  Much of the semantic 
problem is bug fixes in addition to the few minor tweeks in new versions.

I gather that you are aware that 'compiler' disappears in 3.0.

tjr