I am trying to release comfortable dataclass unpacking using `**` operator. Now I have 5 different ways to do it.
But not a single good one. Confused by the implementation of the unpacking operator.
So when I try to unpack any custom class, I get the error:
`type object argument after ** must be a mapping, not MyClass`
Ok, nothing special. I need to use `collections.abc.Mapping` right?
Now I need to implement: `__getitem__`, `__iter__`, `__len__`. Not a problem.
But additionally I get: `keys`, `items`, `values`.
Hey, I don't need them. I don't need the full mapping functionality. I only need the double asterisk to work.
Right, we have a duck typing!
We throw out `abc.Mapping`. What do we need to implement?
It's `__getitem__` and `keys`. Wtf `keys`?
I am looking at Python Data model: https://docs.python.org/3/reference/datamodel.html
There many operators, and they depend on special double underscore methods.
Hmm, I don't see unpack operators there, it's strange.
But why it's `keys`? Because the historical is `dict`?
I think a dependency on `__iter__` is more preferable and expectable over a userspace named `keys`.
Actually, `items()` is more predictable.
But this is not the end.
The `__getitem__` overload is often used for additional checking.
I think `__iter__` and `keys` should only return a valid keys.
Therefore, we don't need to further check them when unpacking. At the very least, we must control this.
And in the end.
`Mapping` keys can be `Any` type. `Unpack` keys must be `str` type.
Some `Mapping` can be unpackable and some `Unpack` can be mappable.
* Add new `collections.abc.Unpack` abstract layout for `**` unpack.
* Add new special method like:
if issubclass(self, collections.abc.Mapping): # Really overload this method in `Mapping` and `dict`.
keys = self.keys() # or return self.items()?
keys = iter(self)
return ((k, self[k]) for k in keys)
* Update the implementation of the unpack operator to use the `__unpack__` function.
As a result:
* We can make the class unpackable without the advanced `Mapping` functionality.
* We can control the unpacking process separately.
* We throw away userspace named dependencies.
* I think we are making behavior more predictable.
What do you think about it?
Python-ideas mailing list -- firstname.lastname@example.org
To unsubscribe send an email to email@example.com
Message archived at https://firstname.lastname@example.org/message/2HMRGJ672NDZJZ5PVLMNVW6KP7OHMQDI/
Code of Conduct: http://python.org/psf/codeofconduct/