[Mlir-commits] [mlir] [MLIR][Python] Register `OpAttributeMap` as `Mapping` for `match` compatibility (PR #174292)

[llvmlistbot at llvm.org]

================
@@ -2629,6 +2639,21 @@ class PyOpAttributeMap {
                     mlirIdentifierStr(namedAttr.name).length));
   }
 
+  nb::object getWithDefaultIndexed(intptr_t key, nb::object defaultValue) {
----------------
MaPePeR wrote:

No, this is also not `__getitem__`. `__getitem__` is bound separately to `dunderGetItem{Named,Indexed }`. `getWithDefaultIndexed` was supposed to handle calls like `op.attributes.get(0, default=builtin.BoolAttr.get(False))` and for that it is also not expect to raise an Exception, even if no `default` is provided. However since there is no ordering for attributes they probably should never really be indexed with a number, except for maybe iterating over them, which is already possible with `__iter__`, `__getitem__`, `.items()`, `.values()` and `.keys()`? So I removed this overload now. `OpAttributeMap.get` now only allows getting an attribute by name.

```python
assert op.attributes.get('some.attribute') == some_attr # returns attribute if it exists or None
assert op.attributes.get('does_not_exist') is None # returns None as default
assert op.attributes.get('does_not_exist', 1234) == 1234
op.attributes.get(0) # raises TypeError
op.attributes.get(0, None) # raises TypeError
match op: 
    case OpView(attributes={0: a}): # raises TypeError
        assert False
```

Since the containers supply their own `__iter__` I don't think python will try to use `get` as a fallback. For `Mapping` its also the other way around: You implement `__getitem__`, but `get` is provided as a Mixin - but that doesn't work for C++ Classes.

https://github.com/llvm/llvm-project/pull/174292