Discussion:
Is there a way to implement the ** operator on a custom object
(too old to reply)
Tony Flury
2024-02-08 12:21:20 UTC
Permalink
I know that mappings by default support the ** operator, to unpack the
mapping into key word arguments.

Has it been considered implementing a dunder method for the ** operator
so you could unpack an object into a key word argument, and the
developer could choose which keywords would be generated (or could even
generate 'virtual' attributes).
--
Anthony Flury
email : ***@btinternet.com
Cameron Simpson
2024-02-09 05:50:21 UTC
Permalink
Post by Tony Flury
I know that mappings by default support the ** operator, to unpack the
mapping into key word arguments.
Has it been considered implementing a dunder method for the **
operator so you could unpack an object into a key word argument, and
the developer could choose which keywords would be generated (or could
even generate 'virtual' attributes).
Can you show us why you think that would look like in code?

Note that Python already has `a ** b` to raise `a` to the power of `b`,
and it has a bunder method `__pow__` which you can define.
Chris Angelico
2024-02-09 06:06:42 UTC
Permalink
On Fri, 9 Feb 2024 at 17:03, Cameron Simpson via Python-list
Post by Cameron Simpson
Post by Tony Flury
I know that mappings by default support the ** operator, to unpack the
mapping into key word arguments.
Has it been considered implementing a dunder method for the **
operator so you could unpack an object into a key word argument, and
the developer could choose which keywords would be generated (or could
even generate 'virtual' attributes).
Can you show us why you think that would look like in code?
Note that Python already has `a ** b` to raise `a` to the power of `b`,
and it has a bunder method `__pow__` which you can define.
I presume this is more like:

obj = SomeObject()
func(**obj)

ie making the object behave in a dict-like way. I can't remember how
this is implemented, but you can create the necessary methods to have
your object produce whatever it likes.

ChrisA
Alan Bawden
2024-02-09 06:26:16 UTC
Permalink
Post by Tony Flury
I know that mappings by default support the ** operator, to unpack the
mapping into key word arguments.
Has it been considered implementing a dunder method for the **
operator so you could unpack an object into a key word argument, and
the developer could choose which keywords would be generated (or could
even generate 'virtual' attributes).
I presume this is more like:

obj = SomeObject()
func(**obj)

ie making the object behave in a dict-like way. I can't remember how
this is implemented, but you can create the necessary methods to have
your object produce whatever it likes.

All you need to do is subclass collections.abc.Mapping, and
implement __len__, __iter__, and __getitem__. Pretty easy.

- Alan
Left Right
2024-02-09 16:09:54 UTC
Permalink
In order for the "splat" operator to work, the type of the object must
populate slot `tp_as_mapping` with a struct of this type:
https://docs.python.org/3/c-api/typeobj.html#c.PyMappingMethods and
have some non-null implementations of the methods this struct is
supposed to contain.

I can do this in C, but I cannot think of a way to do this in Python
proper. Defining all the methods mentioned in PyMappingMethods doesn't
seem to do it. You could try to research this further, and if, indeed
defining all the methods of PyMappingMethods on the Python side
doesn't produce an object that behaves like a proper mapping, you
could probably file a bug report for that.
Roel Schroeven
2024-02-09 17:03:04 UTC
Permalink
Post by Left Right
In order for the "splat" operator to work, the type of the object must
https://docs.python.org/3/c-api/typeobj.html#c.PyMappingMethods and
have some non-null implementations of the methods this struct is
supposed to contain.
I can do this in C, but I cannot think of a way to do this in Python
proper.
Looks like it can simply be done in Python, no tp_as_mapping needed. I
tried it like Alan Bawden suggested (sibling post of yours):

import random # just as an example
import time   # just as an example
from collections.abc import Mapping

class VirtualKwargs(Mapping):

    def __init__(self):
        self.fncs = {
            # Simple examples of functions with varying return values to be
            # called for each lookup, instead of fixed values.
            'time': time.time,
            'random': random.random,
        }

    def __len__(self):
        return len(self.fncs)

    def __iter__(self):
        return iter(self.fncs)

    def __getitem__(self, key):
        return self.fncs[key]()


def func(**kwargs):
    for k, v in kwargs.items():
        print(f'{k}: {v}')


obj = VirtualKwargs()
func(**obj)


Output (obviously changes every run):

time: 1707497521.175763
random: 0.6765831287385126
--
"Man had always assumed that he was more intelligent than dolphins because
he had achieved so much — the wheel, New York, wars and so on — whilst all
the dolphins had ever done was muck about in the water having a good time.
But conversely, the dolphins had always believed that they were far more
intelligent than man — for precisely the same reasons."
-- Douglas Adams
Left Right
2024-02-09 17:56:17 UTC
Permalink
Post by Roel Schroeven
Looks like it can simply be done in Python, no tp_as_mapping needed.
It's not that it isn't needed. You've just shown a way to add it using
Python code.

But, more to the point: extending collections.abc.Mapping may or may
not be possible in OP's case.

Also, if you are doing this through inheritance, this seems really
convoluted: why not just inherit from dict? -- less methods to
implement, less stuff to import etc.
Cameron Simpson
2024-02-09 21:13:23 UTC
Permalink
Post by Left Right
But, more to the point: extending collections.abc.Mapping may or may
not be possible in OP's case.
We don't yet know if that's what the OP had in mind yet, anyway.
Post by Left Right
Also, if you are doing this through inheritance, this seems really
convoluted: why not just inherit from dict? -- less methods to
implement, less stuff to import etc.
There's a rule of thumb that we _tend_ not to subclass the builtins; it
certainly has its pitfalls to do with object creation/initialisation.
That said, I have some classes which subclass dict, int, str and
namedtuple.

Cheers,
Cameron Simpson <***@cskk.id.au>
Stefan Ram
2024-02-10 13:24:39 UTC
Permalink
Post by Cameron Simpson
That said, I have some classes which subclass dict, int, str and
namedtuple.
Consider subclassing
collections.UserDict instead of dict and
collections.UserString instead of str.
Lawrence D'Oliveiro
2024-02-10 21:30:23 UTC
Permalink
Consider subclassing collections.UserDict instead of dict and
collections.UserString instead of str.
The docs <https://docs.python.org/3/library/collections.html> say, for
both of those:

The need for this class has been partially supplanted by the
ability to subclass directly from [the builtin type] ...

I think the recommendation against subclassing builtin types was a
holdover from Python 2.x days.

Loading...