WIP: Element type hinting

NOTE: WORK IN PROGRESS

Why?

Type hinting merely serves the purpose of allowing the parser to write better error messages.

• The parser uses the type hints to validate the non-model parameter arguments passed to the object constructors, for instance to catch this sort of error:

  kat = finesse.Kat()
  kat.parse("""
  l laser P=1
  pd PDtf laser.p1.o freqs=&fsig.f phases=0  # freqs should be a list, not a single number
  """)
  
  k = kat.deepcopy()

  TypeError: line 3: object of type 'int' has no 'len'
  > pd PDtf laser.p1.o freqs=&fsig.f phases=0

  We can use the type hints to instead write:

  line 3: 'freqs' argument to 'laser' should be a sequence, not 'int'
  > pd PDtf laser.p1.o freqs=&fsig.f phases=0

Use of from __future__ import annotations

This enables postponed evaluation of type hints on import. This will become the default behaviour in Python 4. Essentially the difference is that the annotations dict at e.g. Beamsplitter.__init__.__annotations__ contains the first below instead of the second (Python 3 default behaviour). This prevents the execution of code to evaluate type hints until a call to typing.get_type_hints(), so no extra code gets evaluated on import.

# Python 4, Python 3.7+ with from __future__ import annotations
{'name': 'str', 'R': 'float', 'T': 'float', 'L': 'float', 'phi': 'float', 'alpha': 'float', 'Rc': 'float', 'xbeta': 'float', 'ybeta': 'float', 'mass': 'float', 'signal_gain': 'float'}
# Python 3 standard behaviour
{'name': <class 'str'>, 'R': <class 'float'>, 'T': <class 'float'>, 'L': <class 'float'>, 'phi': <class 'float'>, 'alpha': <class 'float'>, 'Rc': <class 'float'>, 'xbeta': <class 'float'>, 'ybeta': <class 'float'>, 'mass': <class 'float'>, 'signal_gain': <class 'float'>}