[Python-3000] PEP 3002 (Procedure for Backwards-Incompatible Changes)

Kay Schluehr kay.schluehr at gmx.net
Fri Apr 28 08:43:19 CEST 2006


Guido van Rossum schrieb:

>I suppose the PEP 3002 proposal was written with the assumption that a
>*syntactic* conversion would be doable purely mechanically, and that
>the semantic issues would be sorted out using a second phase tool. 
>
I have a question towards the syntax/semantics distinction that is 
involved here in migration
issues. Is this boundary a political or a technical one? I'm aware that 
semantical differences cannot
be detected using a static analyzer because type-information is not 
available at compile time but
runtime-type checks could be performed instead. So a "critical function" 
call can be replaced by
a call on a wrapper function that branches along the detected runtime 
types.

Example: In Py3K floor integer divison is expressed using the double 
slash operator // that replaces
the single slash operator used in Python 2.X. We cannot naively 
translate a/b in Python 2.X to a//b
because no type information is available but we can relpace a/b by the 
wrapper newdiv(a,b)

where

def newdiv(a,b):     # Python2.X wrapper of a/b to obtain Py3K behaviour
      if isinstance(a, int) and isinstance(b, int):
          return a//b
      else:
          return a/b

I don't see yet severe limitations to this procedure since Python has 
good reflective capabilities
( even where they don't spring off naturally you can tune them: for 
example if you want to reflect
on the module origin of a certain function it is possible to perform 
automatical annotations using
decorators that are merged with the Python 2.X legacy code on AST level ).

On the other hand this automatical translations are done likely for the 
purpose of letting old Python
code just work on Py3K not extending it as translated source.

Regards,
Kay




More information about the Python-3000 mailing list