Python Sanity Proposal: Type Hinting Solution

Marko Rauhamaa marko at pacujo.net
Sat Jan 24 04:27:12 EST 2015


Steven D'Aprano <steve+comp.lang.python at pearwood.info>:

> Marko Rauhamaa wrote:
>
>>    def weekday(day):
>>        assert isinstance(day, int) and 0 <= day <= 6
>>        ...
>
> [...]
>
> Requiring the type-checker to parse and understand arbitrarily complex
> assertions would require the type-checker to be as complex as Python
> itself:

The static type checker / optimizer would of course be limited to a set
of known fixed expression patterns. More complex expressions would
simply be ignored by it.

Moreover, the type checker would probably operate in a compile-time
environment where you assume "isinstance" and "int" retain their usual
meanings. 

Scheme already employs somewhat analogous dirty tricks like that in its
macro preprocessing.

> Assertions also have the problem that they execute arbitrarily complex
> code at runtime.

Assertions don't *have* to execute anything, anywhere, any time. The
static analysis can decide when executing assertions is worth the
trouble. All of the above can also be done JIT.

> Lastly, this use of assertions clashes with "best practice" for
> assertions. Since assertions may be disabled, you should not use them
> for testing user-supplied arguments. So that means you have to write:
>
> def func(arg):
>     assert isinstance(arg, int)  # satisfy the type checker
>     if isinstance(arg, int):  # support times when assert is disabled
>         ...

I think that's a silly argument. You never second-guess assertions.

> This doesn't apply to annotations:
>
> def func(arg:int):
>     # since this is a public function, not private, we cannot assume the
>     # caller will run the type-checker
>     if isinstance(arg, int):
>         ...

I think that usage is plainly bad style as well. Reminds me of the old
adage:

   Dad is always right, and even when he isn't, he's never wrong.


Marko



More information about the Python-list mailing list