type hinting backward compatibility with python 3.0 to 3.4

[bartc]

On 21/05/2017 06:41, Chris Angelico wrote:
> On Sun, May 21, 2017 at 3:30 PM, Gregory Ewing
> <greg.ewing at canterbury.ac.nz> wrote:
>> Chris Angelico wrote:
>>>
>>> But since Python _does_ work with dynamic evaluation
>>> (which consequently demands that these kinds of things be expressions
>>> evaluated at compile time), it must by definition be possible to have
>>> side effects.
>>
>>
>> In most languages, type declarations are not expressions
>> and aren't evaluated at all in the usual sense, so questions
>> of evaluation order and side effects just don't apply.
>>
>> If we were designing a static typing system for Python from
>> scratch, I would be strongly arguing that type hints shouldn't
>> be expressions evaluated at run time, because it's such a
>> poor fit for the intended use. Introspectable by all means,
>> but evaluated by default, no.
>
> 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?

They might be /created/ at runtime, but it's a pretty good bet that the 
name A in this declaration:

   class A...

is the name of a class. The question in Python, as always, is whether an 
A used as the name of a type in a type, is still this same A. And 
presumably such a type hint can precede the declaration of A.

In fact the declaration of A might be in a different module from its use 
in a type hint, which means that, in the CPython byte-code compiler 
anyway, it is not visible at compile-time, when type hints could best be 
put to good effect.

Furthermore, both A, and the type-hinting code, might be conditional. So 
that on Tuesdays, A is a class, the rest of the week it's the name of a 
module.

Python doesn't make things easy.

-- 
bartc