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

Stephen R Laniel steve at laniels.org
Wed Jun 20 17:22:03 EDT 2007


On Wed, Jun 20, 2007 at 09:41:09PM +0100, Michael Hoffman wrote:
> If you asked Java programmers why you couldn't turn *off* Java's static 
> type checking if you wanted to, you'd probably get a similar response.

Perhaps it would help for me to explain what I'd like.

Under both Perl and Python, I've found myself
having/wanting to write things like so:

def my_func( int_arg, str_arg ):
    try:
        int_arg = int( int_arg )
        str_arg = str( str_arg )
    except ValueError:
        sys.stderr.write( "Args are not of the right type\n" )
        sys.exit(1)

Granted, in a dynamic language we won't always (maybe "won't
often") have a situation where the types are known this well
at compile time. But sometimes we will. And it would be nice
to catch these before the program even runs.

So my question is: would bolting on "static type checking
when we can, no type checking when we can't" be too much
to ask?

My reason for asking initially was that the PEP adds all
kinds of information to the function prototype -- e.g.
(quoting from there)

def foobar( a: Integer, b: Sequence ) -> String:

so why not, I reasoned, use this information at compile
time?

Of course I understand the virtue of writing code with good
doctests, etc. But my question is why we can't get some more
static typing as well. Given the tools that'll be in Python
3.0, that doesn't seem unreasonable to ask.

Apparently it is unreasonable. I'm sorry I asked.

-- 
Stephen R. Laniel
steve at laniels.org
Cell: +(617) 308-5571
http://laniels.org/
PGP key: http://laniels.org/slaniel.key



More information about the Python-list mailing list