Josh Rosenberg <shadowranger+pyt...@gmail.com> added the comment:
object.__ipow__ is documented to take an optional third argument (though there is no way to pass it aside from explicitly calling __ipow__ directly since there is no syntax support for three-arg pow, in place or otherwise), so it's not some incompatibility with object.__ipow__'s signature. How are you seeing garbage passed? In the CPython C code base, I only see PyNumber_InPlacePower called in two places; ceval.c (to handle **=, which only handles two operands) and _operator.c (to implement operator.__ipow__, which unlike object.__ipow__, only takes two arguments, not three). In both cases, the third argument is explicitly passed in as Py_None. PyNumber_InPlacePower itself then passes along that third argument to ternary_op as its third argument, and every code path that calls the retrieved slot consistently passes that argument along as the third argument to the slotted ternaryfunc. I suppose an extension module might incorrectly call PyNumber_InPlacePower without passing the third argument, but that's a problem on their end (and should be caught by the compiler unless all diagnostics are suppressed). But I'm not seeing the problem here. The code path is probably untested (given all numeric types in the CPython core are immutable, so none of them set nb_inplace_pow), but it looks correct at first glance. Do you have code that reproduces the error? ---------- nosy: +josh.r _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue36379> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
