PEP 3107 and stronger typing (note: probably a newbie question)

Dave Baum Dave.Baum at
Thu Jun 21 18:08:54 CEST 2007

In article <mailman.9321.1182402041.32031.python-list at>,
 kaens <apatheticagnostic at> wrote:

> On 6/20/07, Diez B. Roggisch <deets at> wrote:
> > That is exactly the problem - there is no "some more" static typing.
> > There is static typing - or not. You can't have it "just a bit".
> Couldn't a language be made so that if you declared a variable like, say:
> string foo = "I'm a string"
> it would be a string, and always a string, and if you declared a variable like
> foo = "i'm a dynamic variable"
> it would be considered dynamic?
> This doesn't seem like it would be too hard to add in to a language
> that already had dynamic typing (But then again, I am inexperienced -
> although interested in - language design).
> It seems to me like this could be really useful, but I'm not aware of
> any language implementing something like this.

Common Lisp has a mechanism similar to what you described.  In general, 
variables are completely dynamic.  However, it is possible to declare 
individual variables to be of specific types.  There are also 
declarations that allow you to specify your preferences for speed versus 
safety.  The upshot of all of this is that the language is a dynamic 
language most of the time, but the programmer can choose to give the 
compiler a bit more information, and with that information a good 
compiler can generate more efficient code (often competitive with the 
speed of C code).

The Common Lisp approach is not without its problems (for one thing, a 
lot of the behavior when type declarations are not met is implementation 
dependent).  But I think there are some ideas in there that could be 
applied to Python.

On the other hand, I'm pretty happy with Python/SWIG/C++ for performance 
critical code, so I'm not sure if optional static typing would really be 
of much use unless the Python compiler got *very* good at generating 
optimized code when declarations were present.

I still think it would be handy to easily specify the expected types of 
function arguments.  I sometimes write code in this pattern:

def foo(a, b):
    "a, b - instances of Bar"
    assert isinstance(a, Bar)
    assert isinstance(b, Bar)
    # do some stuff

Note that the expectation that 'a' and 'b' are to be of type Bar is 
specified twice: once for a runtime check, once for the docstring.  It 
might be nice if there were a mechanism to specify it once and have the 
docstring and runtime check both make use of that information:

>>>def foo(Bar a, Bar b):
>>>    # do some stuff

>>>foo(1, Bar())
TypeError: argument a is not of type Bar

foo(Bar a, Bar b)

On the downside, this sort of mechanism might do more harm than good.  
For one thing, it would really clash with duck typing.  For another, 
anyone coming to Python from Java/C++ would probably use those 
declarations *everywhere*, even when there isn't a good reason to limit 
the type.


More information about the Python-list mailing list