In some code we have the first 5-10 lines are basically in the shape of : assert isinstance(arg1, type) assert isinstance(arg2, SubObjectClass) And so on. Mainly because we deal in code that deals a lot with traditional types (as in signed 8 bit, Strange-Endian 32bit in 16bit words , and so on) which makes code turn nasty in pretty much any language.

Further down these are cast into more native types, and then walk out into public API's.

And there once more you need to do somewhat strict data-validation.

For these cases, typing rules and annotations will be a boon.

And do note, that there is more common a case of human error or refactoring error that causes problem. Someone sending in a default [] array in an object, and somewhere else it's an expected Boolean.

Thanks :)

That matches well what I had in mind with my "a." suggestion.

Now, why cannot we expect "b. Better performance thanks to enforced type letting the compiler do a better job"? Are the semantics of what's being discuss insufficient to provide such benefits? I'm asking that question because I read often that dynamic typing is the #1 performance hit of Python (e.g. [1]). Now that this PEP lets developers provide and enforce type, what's still in the way of reaching the level of performance of statically-typed languages?

[1] Alex Gaynor - Fast Python, Slow Python: https://www.youtube.com/watch?v=7eeEf_rAJds

I don't think the Python VM will use these as actual hints, it's mainly to help refactoring tools and people maintaining large codebases as I understand it. No type is "enforced".

> For these cases, typing rules and annotations will be a boon.

You can use PEP3107 annotations today and automatically validate them using a decorator to eliminate boilerplate code like that. They don't have to be something to look forward to tomorrow.

Related: https://github.com/kislyuk/ensure

A (relatively) high performance runtime annotation type checker.

    from ensure import ensure_annotations
    
    @ensure_annotations
    def f(x: int, y: float) -> float:
        return x+y

(b) is possible as well, but it would probably happen in PyPy or Cython, rather than CPython.