Skip to content

Create a static version of the IfcOpenShell hl Python API #2693

@aothms

Description

@aothms

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?

Metadata

Metadata

Type

No type

Projects

Relationships

None yet

Development

No branches or pull requests

Issue actions