get_info_2 advertises the same signature as get_info but raised a bare
AssertionError for anything the C++ fast path does not implement --
including its own default arguments (recursive=False).
Use the fast path when recursive=True, return_type=dict and ignore=()
hold, and delegate to the pure Python get_info otherwise. As noted in
the issue, without recursion there is no meaningful performance gain to
lose by delegating.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Stop iterating early and don't build a list to make it a bit more optimized.
Though I'm unsure if anyone is really using `unpack_non_aggregate_inverses`
cc @Andrej730 we need this for validate.buildingsmart.org because for express rule evaluation we depend on include_id=False and entity_instance.__eq__ has been changed to get_info_2.
Example of the error:
Traceback (most recent call last):
File "\test.py", line 133, in <module>
ifc_file = ifcopenshell.file.from_string(ifc_str)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "\ifcopenshell\file.py", line 648, in from_string
return file(ifcopenshell_wrapper.read(s))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "\ifcopenshell\file.py", line 264, in __init__
raise exc(msg)
ifcopenshell.SchemaError: Unsupported schema: IFC2X3
Exception ignored in: <function file.__del__ at 0x00000250896EB740>
Traceback (most recent call last):
File "\ifcopenshell\file.py", line 282, in __del__
del file_dict[self.file_pointer()]
^^^^^^^^^^^^^^^^^
File "\ifcopenshell\file.py", line 424, in __getattr__
return getattr(self.wrapped_data, attr)
^^^^^^^^^^^^^^^^^
File "\ifcopenshell\file.py", line 424, in __getattr__
return getattr(self.wrapped_data, attr)
^^^^^^^^^^^^^^^^^
File "\ifcopenshell\file.py", line 424, in __getattr__
return getattr(self.wrapped_data, attr)
^^^^^^^^^^^^^^^^^
[Previous line repeated 996 more times]
RecursionError: maximum recursion depth exceeded
Simple way to trigger those recursions was:
import ifcopenshell
ifcopenshell.file(schema="IFC4x3_RC4_43c3555")
ifcopenshell.entity_instance(("IFC4X3", "IfcPresentationStyleAssignment"))
TypeError is more correct since error occurs when user is trying to set some attribute value with None while atttribute doesn't support None type. ValueError is typically raised when provided value has a correct type but unsupported value.
Thomas Krijnen