Re: [PATCH v3 07/15] devicetree: Add DeviceTree live tree representation

[Doug Anderson]

Hi David,

On Wed, Nov 4, 2026 at 4:44 AM David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> wrote:
>
> > +class Property(bytes):
> > +    """Holds a device tree property name and value.
> ...
> > +    """
> > +    def __new__(cls, name, value=b''):
> > +        if not isinstance(value, (bytes, bytearray)):
> > +            raise TypeError(f"Expected bytes or bytearray, got {type(value).__name__}")
> > +        obj = super().__new__(cls, value)
> > +        obj.name = name
> > +        return obj
>
> Thanks!  I do wonder if we're doing this if we should update __eq_ and
> __hash__ methods to take into account the property name.

I don't think we can include `self.name` in `Property.__eq__` and
`Property.__hash__` without breaking `Property` comparisons against
plain `bytes`:

1. `fdt.getprop(node, name)` returns a `Property`, and existing callers
   (including 10 assertions in `tests/pylibfdt_tests.py`, such as
   `self.assertEqual(prop, b'test_tree1\0')`) compare `Property`
   directly with `bytes`. If `Property.__eq__` required `other` to be a
   `Property` with the same `.name`, `prop == b'...'` would evaluate to
   `False`.

2. If `Property.__eq__` only compared `self.name == other.name` when
   `isinstance(other, Property)` and still allowed `prop == b'...'` for
   plain `bytes`, then:
   - `==` would no longer be transitive (`Property('a', b'x') == b'x'`
     and `Property('b', b'x') == b'x'`, yet
     `Property('a', b'x') != Property('b', b'x')`).
   - Python's data model requires `a == b` to imply `hash(a) == hash(b)`,
     so `hash(Property('a', b'x'))` must equal `hash(b'x')` if
     `Property('a', b'x') == b'x'` is `True`.

In `DeviceTree`, properties are stored in `node.props` keyed by
`prop.name`, so `node1.props == node2.props` already compares both the
property names and the byte values.

What do you think?


-Doug