4 ms·

This is a very nice article showing some of the issues troubling python and the proposed type anotations. I would summarize my view of the type annotation prop

by wirrbel 12y ago

This is a very nice article showing some of the issues troubling python and the proposed type anotations. I would summarize my view of the type annotation proposal as follows: Statically typed languages can introduce inference heuristics that minimize the amount of type declarations. They can "jump" into the dynamically typed world more easily. The other way around is a lot harder. Not only are all those type annotations lacking in the standard library and the tools around, but there is also a lack of function design by types.

rurban 12y ago
No, it's a horrible article. And no, they cannot. I implemented such a type inferencer for perl (B::CC), which has the exact same problem. With a highly dynamic run-time which changes the types at will, the compiler will never be able to do proper optimizations without explicitly forbidding certain coercions. The inferencer has to give up in 90% of all cases. Only with optional explicit types, esp. for loop counters and array members, those operations can be efficiently optimized. Up to 2000% for the typical array or loop benchmarks. And no, a v8-style tracing jit also does not help in all cases. This kind of run-time type caching has a huge overhead, and will always need an explicit run-time check, and does not catch the typical type errors writing programs. It helps with simple scripts, but not with programs. You don't have to worry. If you don't like to use types, don't use it. Nothing will change. It will only compile-time optimize and check the cases where someone added the types. Of course the standard library is free to add type-optimized versions later, as e.g some Common Lisp's did with their arrays and vectors. But this was done mostly in the compiler, not in the library itself.
- wirrbel 12y ago
  You are right about optimizations, there are a lot of situations where type annotations could greatly help the compiler. I just do not have the feeling that performance optimizations in CPython are the reason for Guido's proposal. It rather seems to be motivated for development tooling. Is `for i in xrange(10000):` especially optimized in python at the moment? I doubt it and those low hanging fruits could be tackled with some explicit pattern matching. (I probably should do my homework now and dive into the python source code).

by wirrbel 12y ago

rurban 12y ago

No, it's a horrible article. And no, they cannot. I implemented such a type inferencer for perl (B::CC), which has the exact same problem. With a highly dynamic run-time which changes the types at will, the compiler will never be able to do proper optimizations without explicitly forbidding certain coercions. The inferencer has to give up in 90% of all cases. Only with optional explicit types, esp. for loop counters and array members, those operations can be efficiently optimized. Up to 2000% for the typical array or loop benchmarks. And no, a v8-style tracing jit also does not help in all cases. This kind of run-time type caching has a huge overhead, and will always need an explicit run-time check, and does not catch the typical type errors writing programs. It helps with simple scripts, but not with programs. You don't have to worry. If you don't like to use types, don't use it. Nothing will change. It will only compile-time optimize and check the cases where someone added the types. Of course the standard library is free to add type-optimized versions later, as e.g some Common Lisp's did with their arrays and vectors. But this was done mostly in the compiler, not in the library itself.

wirrbel 12y ago
You are right about optimizations, there are a lot of situations where type annotations could greatly help the compiler. I just do not have the feeling that performance optimizations in CPython are the reason for Guido's proposal. It rather seems to be motivated for development tooling. Is `for i in xrange(10000):` especially optimized in python at the moment? I doubt it and those low hanging fruits could be tackled with some explicit pattern matching. (I probably should do my homework now and dive into the python source code).