Proposal: local variable declarations and type advice

Paul Rubin phr-n2002a at nightsong.com
Tue Feb 26 02:19:20 EST 2002


"logistix" <logstx at bellatlantic.net> writes:
> The type advice is really impossible in a dynamic language and it's not
> going to help out a native compiler anyways.  A better example (than Example
> 2) of code biting you in the ass is:

Of course it's possible in a dynamic language, and it helps compilers.
Lisp compilers have worked that way since the 60's or even earlier.

> def foo(x):
>     local y(int)
>     y = x
> 
> This will only be able to successfully statically analyze if every call made
> to foo is passing in a statically typed value.  So for any of the "advice"
> to work, all vars need to be typed. 

Obviously that example can't be checked statically by the compiler.
It can be checked dynamically at runtime (debug mode) or the compiler
can generate code that assumes the advice is correct and which crashes
if the advice is wrong (optimized mode).

> This is exactly the way you have to validate info in "real
> languages" like C++ (and I imagine java). RTTI is required if your
> class heirarchies get too crazy for static checking (such as a toy
> lisp interpreter I wrote, all lisp objects inherited from a base
> "object" class).

If you've written a toy Lisp implementation, you might also like to
look at how a real Lisp compiler works.  They use declarations for
optimized code generation, while remaining dynamic.  

> This would remove all dynamic properties from python, which is
> probably undesirable.  If you do need/want to validate the type at
> runtime, you might as well use the builtin type() function.

Why would I want to use the builtin type() function everywhere I want to
validate the type, if Python can do the check for me automatically based
on the type advice?



More information about the Python-list mailing list