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.

My suggestion:
* Add new `collections.abc.Unpack` abstract layout for `**` unpack.
* Add new special method like:

def __unpack__(self):
    if issubclass(self, collections.abc.Mapping):  # Really overload this 
method in `Mapping` and `dict`.
        keys = self.keys()  # or return self.items()?
    else:
        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 -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/2HMRGJ672NDZJZ5PVLMNVW6KP7OHMQDI/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to