Hacker News new | past | comments | ask | show | jobs | submit login

There's one thing that doesn't sit well with me about adding type-checking to the CPython implementation of the Python language. Type-checking is generally used at compile-time to check that your program won't do nasty things, and then run-time checks are done only when you do something overly dynamic that the compiler couldn't check (i.e. casting an Object to some concrete class in Java). However, all type-checking implementations for CPython work purely at runtime! And type-checks are invoked each time your function is called! This seems not only wasteful, but also defeats the purpose of type-checking before running your program.

I would rather see a more generic pre/post-condition contract system, to be used in select top-level functions, that gives a lot more flexibility in expressing what is supposed to happen (i.e. I expect to be given a not-None value with a __str__ method that doesn't throw and will return an iterator yielding consecutive not-empty, not-None strings), including what assumptions you're making when you call a function that you got from a random object (i.e. here I'm calling a function that I got somehow as a parameter and I'm going to assume it can take a string of the format "ipv4 address:port" and returns an object that is a database connection), together with a mechanism for recovering from broken contracts - we are doing runtime checks, so there's no reason to restrict ourselves to Java-style type constraints, which don't even work for Python in general. Or, alternatively, a lighter system that can be checked at import time once before the program is started "for real". Preferably both of those.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: