replacing the __call__ function and creating a new type instance on Pyo3 side in Rust

[markusdd]

Ok, so this is some major metaproogramming question. Rationale:

In our project we have a plethora of type/class instances which have the same signature and are frozen after creation, hence the instances can be shared. But an upfront singleton type approach is not really practical for our purposes. For that there exists already a Python package called mementos which implements the Memento-pattern:
https://pypi.org/project/mementos/

It is relatively simple: It creates a dict key out of the class and it's calling signature, saves the instance in a dict, and overrides the call function of a class that inherits the metaclass menentos. If the class is being created somewhere else with the same signature, the same instance is returned again instead of creating a new one.

As this inital creation and lookup is very performance critical in our project we want to try if we can gain anything by essentially re-implenting this in rust. I just tried to replace the key generation functioon and this actually made it slower, soo now I am looking into moving the whole dict into a rust hashmap and just handing in the signature and retuning a new or cached instance, so essentially I want to oxidize this call function from the mementos package, alternatively one could also replace the whole outer metaclass factory but that might not be worth it:

_memento_cache = {}

def memento_factory(name, func):
    """
    Return a memoizing metaclass with the given name and key function.
    That makes this a parametrized meta-metaclass, which is probably
    the most meta thing you've ever seen. If it isn't, both congratulations
    and sympathies are in order!
    """

    def call(cls, *args, **kwargs):
        key = func(cls, args, kwargs)
        try:
            return _memento_cache[key]
        except KeyError:
            instance = type.__call__(cls, *args, **kwargs)
            _memento_cache[key] = instance
            return instance

    mc = type(name, (type,), {"__call__": call})
    return mc

My problem are the calls to 'type'. I cannot really find the equivalent for that in pyoo3, oor I misunderstand the docs.
Or can I just create the instance based on cls which is handed to me?
If I write cls.call(*args, **kwargs) in python that will lead to infinite recursion.

Any tips are appreciated.

[davidhewitt]

Could you fetch type from builtins? e.g. py.import("builtins")?.getattr("type)?

[davidhewitt]

Are you building with --release? Also, my intuition is that rewriting this function in Rust isn't going to yield much performance speedup, because it's a relatively light Python function and the Rust implementation is heavily calling into Python anyway.

Regarding the difference between Python and Rust cls type, I am afraid I don't have an answer there. The details may lie in the implementation of type().

[markusdd]

yes I am building with --release.

You might be correct that no substantial speedup is to be expected here, but seeing a 6x slowdown is equally unexpected.

My issue with the cls datatype is that in my view just nesting it into another function does actually absolutely nothing, that is what I find utterly confusing.

One other idea: can the import of type be pulled out to be permanent?
I could imagine reimporting on every call might be expensive.

[birkenfeld]

The answer here lies in the descriptor behavior (__get__) that Python defined functions have, and that "C functions", which PyO3 also uses, lack. The latter cannot be used as methods without being specially wrapped by being defined in the PyMethodDef list for the class.

The C functions do not get implicitly passed the instance (normally self, here cls) as the first argument. Therefore, in the Rust function what you're getting as cls is simply the first argument being split from *args: the class name as a string.

[birkenfeld]

Here is a simple PyO3-free example demonstrating this:

import _testcapi

def py_meth(*args):
    return args

c_meth = _testcapi.get_args

print(py_meth(1, 2, 3))
print(c_meth(1, 2, 3))

py_type = type("A", (object,), {"__call__": py_meth})
c_type = type("B", (object,), {"__call__": c_meth})

print("---")
print(py_type()(1, 2, 3))
print(c_type()(1, 2, 3))

(_testcapi.get_args is a simple test C function defined just like py_meth is here: it returns all its positional arguments as a tuple.)

Output:

(1, 2, 3)
(1, 2, 3)
---
(<__main__.A object at 0x7faa654e6e90>, 1, 2, 3)
(1, 2, 3)

[markusdd]

@birkenfeld You sir just blew my mind haha

But it makes complete sense of course. I once learned this when I started using Python more than a decade ago but as this is somethign you normally never bother with it kind of did not come to my mind when debugging this.

Question is: would there be a way to circumvent this? Or is it anyway not worth the effort?

You mentioned PyMethodDef...can we inject the rust call function in a more effective manner than just wrapping it into a python function?

Or is there a way to completely replace the whole python mementos module?
I am not quite sure how I would handle creation of the metaclass, but if this would work we would surely save some calling overhead.