Is (and/or Why) __str__, __repr__ are not patchable? about forbiddenfruit

[alendit]

Hi, I assume it applies to all "dunders"? I.e. I tried to patch __matmul__ on FunctionType to implement function chaining. And although f.__matmul__(g) does the right think, f @ g doesn't seem to pick up the existence of the overwritten implementation.

Of course, f.chain(g) would do, too, but the ability to override the operator behaviour would add a wholly another level of the black magic and let me maniacally laugh at the code reviewer's tears, so it would be incredibly useful, as you might imagine.

[phy1729]

I happen to be working in the same area. Looking to add __next__ which is proving troublesome because it can raise an exception. But I've added __repr__ and __hash__ on phy1729/complete-PyTypeObject

[soamicharan]

please also add __getattr__ for patching

[clarete]

Hello, sorry for the late response. forbiddenfruit is a really [lame] simple hack that exposes the __dict__ attribute of a python class. Magic methods and special protocols are resolved separately. forbiddenfruit would have to special case these methods and overwrite the right properties in the PyObject struct to allow patching these special guys.

It's possible but might take some digging to find out what to overwrite.

[alexchandel]

This is resolved for methods defined in ff's PyTypeObject._fields_ or one of its method suites (e.g. PyNumberMethods) and added to override_dict. __repr__, __hash__, __call__, __iter__, and __next__ are still missing.

[pschanely]

Just a quick +1 for getting __repr__ working; it would enable symbolic reasoning about repr strings in CrossHair.

[RadiantUwU]

__hash__ also doesnt work

[RadiantUwU]

Right now, im trying to patch hash on the forbiddenfruit module

[MrFizzyBubbs]

+1 for __call__