Given csp's ts[] duality in csp.node its convenient to annotate inputs as their non-ts types within the node for better IDE support.
CSP wont allow these annotations before csp.start/alarms/state blocks because csp enforces that these blocks be at the start of the method. We can / should relax this constraint to allow bare annotation lines to be declared though, since its more natural to list these up front next to the function signature
import csp
@csp.node
def foo(x:csp.ts[int]):
x : int
with csp.start():
s_foo = None
Traceback (most recent call last):
File "/home/ra7293/.config/JetBrains/PyCharm2025.2/scratches/scratch_27.py", line 3, in <module>
@csp.node
^^^^^^^^
File "/home/ra7293/user/github/csp/csp/impl/wiring/node.py", line 280, in node
with ExceptionContext():
^^^^^^^^^^^^^^^^^^
File "/home/ra7293/user/github/csp/csp/impl/error_handling.py", line 44, in __exit__
raise exc_val.with_traceback(new_tb)
File "/home/ra7293/.config/JetBrains/PyCharm2025.2/scratches/scratch_27.py", line 4, in <module>
def foo(x:csp.ts[int]):
^^^^^^^^^^
File "/home/ra7293/.config/JetBrains/PyCharm2025.2/scratches/scratch_27.py", line 4, in <module>
def foo(x:csp.ts[int]):
^^^^^^^^^^
File "/home/ra7293/.config/JetBrains/PyCharm2025.2/scratches/scratch_27.py", line 4, in <module>
def foo(x:csp.ts[int]):
^^^^^^^^^^
csp.impl.wiring.base_parser.CspParseError: Invalid usage of start, it should appear at the beginning of the function (consult documentation for details)
Given csp's ts[] duality in csp.node its convenient to annotate inputs as their non-ts types within the node for better IDE support.
CSP wont allow these annotations before csp.start/alarms/state blocks because csp enforces that these blocks be at the start of the method. We can / should relax this constraint to allow bare annotation lines to be declared though, since its more natural to list these up front next to the function signature
Example
Leads to