type hinting backward compatibility with python 3.0 to 3.4

[Chris Angelico]

On Sun, May 21, 2017 at 7:15 PM, Gregory Ewing
<greg.ewing at canterbury.ac.nz> wrote:
> Chris Angelico wrote:
>>
>> How do you declare that a parameter must be an instance of some class?
>> Classes are themselves created at run time. Or would your typing
>> system require that all types be created in some declarable way?
>
>
> Types that you want statically checked have to be described
> in a declarative way, because the description is going to be
> processed by a tool that is not executing the program.
>
> You wouldn't be able to put a type that can't be described
> declaratively into a type annotation, but there would be no
> reason to do so in the first place.

That kind of difference is fine with an external tool, but it'd make
the language itself inconsistent. For (say) mypy to be able to check
your code, it needs to be able to figure out what classes exist. Fine,
no problem. But for CPython to be able to run your code, it needs to
be able to syntactically verify everything. With mypy, if your classes
are too dynamic, you might have to create a stub file that's more
static (but non-functional) just for the type checking. Can you do
that if your type checker is part of the language? What happens if the
stub file is flat-out wrong? (Again, with mypy, all you break is the
type checker.)

There's a lot of difference between PEP 484 type hints and C-style
static typing. Or even PEP 484 and Pike-style type hinting, where you
can say "object(implements yada yada)" and you'll generally mean "yada
yada or a subclass thereof" (though not necessarily). Pike's static
type checks are only useful if the type in question exists in a static
context - otherwise you have to just use "object" or some other parent
class. (Or just ignore type checking for that. It's a
dynamically-typed language, so static checking is as optional as it is
in Python.)

ChrisA