[zrgt]

Attributes like Submodel.submodel_element, Qualifiable.qualifier or
HasExtension.extension hold a NamespaceSet, while the corresponding
__init__ parameters accept any Iterable. Assigning an iterable to
such an attribute after initialization silently replaced the
NamespaceSet with that plain object. The old NamespaceSet remained
registered in namespace_element_sets, so its objects stayed reachable
via get_referable() and friends while being invisible in the
attribute, uniqueness constraints were no longer checked and the
parent of the new objects was never set. The resulting errors, such as
AttributeError: 'list' object has no attribute 'update_nss_from' when
iterating over an ObjectStore, gave no hint about the actual cause.

Assignments to such an attribute are now redirected to the content of
the existing NamespaceSet, which is the behavior a user would expect
from the type of the __init__ parameters:

submodel.submodel_element = [my_property]  # replaces the content of the set
aas.extension = []                         # clears the set

This is done by the reusable NamespaceSetAttribute descriptor, which is
declared once per attribute that holds a NamespaceSet. Hooking only
those attributes, instead of overriding Namespace.__setattr__, leaves
every other attribute write at its original speed. extension and
qualifier are declared on HasExtension and Qualifiable, so they
cover every current and future subclass, including classes defined
outside of this repository. The existing SubmodelElementList.value
setter keeps working unchanged.

The replacement is atomic: if one of the new objects violates a
constraint, the previous content of the set is restored, so a failed
assignment leaves the object untouched.

Fixes #65

[s-heppner]

Depends on #661, since otherwise our Registry service would be broken.

[s-heppner]

This __setattr__ override runs on every attribute write of every Namespace subclass, and that has a measurable cost. Object construction is about 3× slower than on the merge base:

Benchmark	Merge base	This PR
Property("P", Int, 1)	~6 µs	~18 µs
Submodel with 20 Propertys	~135 µs	~390 µs

import timeit
from basyx.aas import model

f = lambda: model.Submodel(
    "urn:sm",
    submodel_element=[model.Property(f"P{i}", model.datatypes.Int, i) for i in range(20)],
)
print(min(timeit.repeat(f, number=500, repeat=5)) / 500 * 1e6, "µs")

This affects every deserialization and every backend that builds objects, so large models will feel it. Most of these writes never touch a NamespaceSet attribute.

Could we hook only the attributes that actually hold a NamespaceSet? One option is a property (or a small reusable descriptor) per attribute, like the existing SubmodelElementList.value setter and like we agreed in #65. Then normal attribute writes keep their current speed.

[s-heppner]

assign() clears the set before it reads items. If items is a lazy iterable over the same set, iterating it fails:

sm = model.Submodel("urn:sm", submodel_element=[
    model.Property("P1", model.datatypes.Int),
    model.Property("P2", model.datatypes.Int),
])
sm.submodel_element = filter(lambda x: x.id_short == "P1", sm.submodel_element)
# RuntimeError: dictionary changed size during iteration

The self.clear() leaves the set unchanged, which is good, but we'd lose functionality that currently works on develop.
One could argue that the actual set should not be accessed, but filtering a set into itself (like above) is a pretty common thing to write imo. Reading items into a list first fixes it:

Suggested change

	self.clear()
	new_items: List[_NSO] = list(items)
	previous: List[_NSO] = list(self)
	self.clear()
	try:
	for item in new_items:
	self.add(item)

A test with a generator or filter() over the set itself would cover this case.

[zrgt]

Fixed in a2a6045: assign() now does list(items) before self.clear().

Added test_assignment_of_lazy_iterable_over_the_same_set, which covers both your filter() example and a generator expression over the set.

---

Generated by Claude Code

[zrgt]

You were right, and the slowdown is bigger than the __setattr__ body suggests: Property("P", Int, 1) performs 30 attribute writes, none of which touches a NamespaceSet.

a2a6045 drops the __setattr__ override for a reusable descriptor, NamespaceSetAttribute, declared once per attribute that holds a NamespaceSet — on HasExtension.extension and Qualifiable.qualifier, so all their subclasses are covered, and on the seven per-class attributes in submodel.py. OrderedNamespaceSetAttribute is the same descriptor with a narrowed __get__ type.

Your benchmark, CPython 3.12, best of 7:

Benchmark	Merge base	__setattr__	Descriptor
Property("P", Int, 1)	2.57 µs	8.17 µs	2.73 µs
Submodel with 20 Propertys	65.5 µs	187 µs	68.2 µs

What is left is one descriptor call per NamespaceSet attribute in __init__, where a NamespaceSet was constructed anyway.

Two side effects worth noting:

• The descriptor also types the assignment (__set__ takes Iterable[_NSO], __get__ returns the set), so the # type: ignore[assignment] comments on these assignments are gone.
• This no longer depends on Fix NamespaceSet handling in Descriptor initialization and update_from() #661. Descriptor.update_from() iterates vars(other), which now yields the private storage attribute rather than extension, so it rebinds as it does on develop instead of going through assign(). The registry is unaffected; whether that rebinding is correct is Fix NamespaceSet handling in Descriptor initialization and update_from() #661's question, not this PR's.

Checks on sdk: 278 tests pass (8 skipped — JSON/XSD schemas and CouchDB not available locally), mypy and ruff clean, Sphinx builds with -n -W, coverage 89 %. compliance_tool and server mypy/ruff clean, their tests unchanged (the two server test errors reproduce on the merge base).

---

Generated by Claude Code

[zrgt]

CI on a2a6045 is green except server-test (3.12) (and server-test (3.11), cancelled by fail-fast). That failure is not this PR's:

• All 124 errors are TypeError: check() got an unexpected keyword argument 'attribute', raised from basyx/aas/model/_string_constraints.py in site-packages — the job tests the server against the PyPI SDK release, not the local one. Nothing in this PR touches _string_constraints.
• develop itself fails identically: run 39418262596 on 2773ac0, same 124 errors, same message.
• The server-test job does not exist in this branch's .github/workflows/pr.yml; it reaches the PR through the merge with develop.

This is #662: the job checks out shallow, so setuptools_scm versions the local SDK below the server's basyx-python-sdk>=1.0.0 constraint and pip install .[dev] replaces it with the release. The documented fix is fetch-depth: 0 on that job's checkout, as the other jobs already do. No fix PR exists yet, and porting a workflow change for a job this branch does not even define would widen this PR into unrelated CI work, so I left it alone.

I also did not spend a re-run on it: the cause is deterministic, and develop being red the same way is stronger evidence than a re-run would be.

---

Generated by Claude Code