[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