Add type constraint assertions and pre-conditions for function inputs

[thanhnguyen-aws]

Description of changes: Add type constraint assertions and pre-conditions for function inputs

Limitation: This PR does not add type constraint for class methods. An upcoming separate PR will unify functions translation with class's methods translation.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[shigoel]

@thanhnguyen-aws Could you please resolve merge conflicts?

[keyboardDrummer]

Have you considered using the constrained types feature from Laurel that @fabiomadge merged recently? It means that instead of generating preconditions you'd generate constrained types and reference these in the function parameters.

Currently that implementation also generates preconditions like this one does, but when using constrained types there is the potential to have more checking be done statically through the type system, for example when you pass a variable to a function that already has the same constrained type.

@andrewmwells-amazon thoughts?

[thanhnguyen-aws]

Currently that implementation also generates preconditions like this one does, but when using constrained types there is the potential to have more checking be done statically through the type system, for example when you pass a variable to a function that already has the same constrained type.

I don't think it is convenient using that feature for this PR because for each union of types, we need to define a constrained type for it.

[thanhnguyen-aws]

@thanhnguyen-aws Could you please resolve merge conflicts?

I resolved the conflict.

[keyboardDrummer]

Currently that implementation also generates preconditions like this one does, but when using constrained types there is the potential to have more checking be done statically through the type system, for example when you pass a variable to a function that already has the same constrained type.

I don't think it is convenient using that feature for this PR because for each union of types, we need to define a constrained type for it.

Indeed you would need a unique constrained type for each union. I don't think that's necessarily as issue, but if the constrained type is only referenced once then it's rather pointless to generate it. I think it's usefulness depends on what type of Python programs we receive.

[keyboardDrummer]

Left a few small comments, but otherwise seems good to me. I would appreciate the second reviewer having more context on the PythonToLaurel code.

[aqjune-aws]

It seems there is a merge conflict, and it could possibly be related to Joe's patch. Do you want to resolve the merge conflict?