We have a wonderful high level API, kudos to everybody involved.
We were also all in agreement with the ifcopenshell.api.run("module.function", ...args) kind of approach. By centrally invoking all API functionality through a central function we eliminate boiler-plate within the individual API functions and we are in really good shape to run API calls e.g collaboratively on a central server!
However, I think the python ecosystem is more and more evolving towards static type decorations. Our approach makes the required arguments of a call completely opaque at the call site so we can't benefit from the static analysis built into IDEs these days. And, tbh, we've seen quite a couple of test cases failing lately due to mismatching in arguments passed to API functions.
Here's a plan. Why don't we at the cmake install step [0] generate [1] [2] static equivalents of all the API usecases?
Thoughts?
api/aggregate/assign_object.py
class Usecase:
def __init__(self, file, product=None, relating_object=None):
...
api/aggregate/__init__.py
# existing content
# ...
# appended at install
def assign_object(file : ifcopenshell.file, product : ifcopenshell.entity_instance = None, relating_object : ifcopenshell.entity_instance = None) -> ifcopenshell.entity_instance:
# [doc_string]
ifcopenshell.api.run("aggregate.assign_object", file, product=product, relating_object=relating_object)
[0] https://github.com/IfcOpenShell/IfcOpenShell/blob/v0.7.0/src/ifcwrap/CMakeLists.txt#L95
[1] I think that would be install(SCRIPT or install(CODE, but maybe add_custom_command(<target> POST_BUILD) or add_custom_target() + add_dependency() would also work?
[2] For python parsing is it ast.parse() or is there sth more convenient specific-purpose we can use?
We have a wonderful high level API, kudos to everybody involved.
We were also all in agreement with the
ifcopenshell.api.run("module.function", ...args)kind of approach. By centrally invoking all API functionality through a central function we eliminate boiler-plate within the individual API functions and we are in really good shape to run API calls e.g collaboratively on a central server!However, I think the python ecosystem is more and more evolving towards static type decorations. Our approach makes the required arguments of a call completely opaque at the call site so we can't benefit from the static analysis built into IDEs these days. And, tbh, we've seen quite a couple of test cases failing lately due to mismatching in arguments passed to API functions.
Here's a plan. Why don't we at the cmake install step [0] generate [1] [2] static equivalents of all the API usecases?
Thoughts?
api/aggregate/assign_object.pyapi/aggregate/__init__.py[0] https://github.com/IfcOpenShell/IfcOpenShell/blob/v0.7.0/src/ifcwrap/CMakeLists.txt#L95
[1] I think that would be
install(SCRIPTorinstall(CODE, but maybeadd_custom_command(<target> POST_BUILD)oradd_custom_target()+add_dependency()would also work?[2] For python parsing is it
ast.parse()or is there sth more convenient specific-purpose we can use?