> > This is exactly the same as what binary_op1() does. I added this > > twist intentionally because of a use case where a subclass of a > > numeric type wants to override a binary (or ternary) operator defined > > by the base class. > > I don't think you understand what I mean. I'm talking > about *in-place* operations. You're right, I hadn't realized that this was about inplace. > For in-place binary operations we have, e.g. > > INPLACE_BINOP(PyNumber_InPlaceSubtract, nb_inplace_subtract, nb_subtract, "-=") > ^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^ > > Both the in-place and non-in-place slots are passed to > binary_iop, which uses the in-place slot for the first > operand and the non-in-place slot for the second. > > But ternary_op only gets *one* slot passed to it, which it > uses for everything. When doing an in-place ternary op, > this is the in-place slot. What this seems to mean is > that, if we have isinstance(a, A) and isinstance(b, B) > and issubclass(B, A), then > > a **= b > > has the potential to in-place-modify b instead of a! Not quite -- the arguments won't be reversed, but it may call B's inplace power function with an A instance as the first argument. This can return NotImplemented if it doesn't know what to do in that case. > It seems to me that there ought to be a ternary_iop > routine that does for ternary ops what binary_iop does > for binary ones. Or we could just document the status quo. It's a pretty esoteric case -- numeric types are traditionally immutable so don't have to implement inplace power at all, and non-numeric types aren't very likely to implement ** at all, let alone **=. The correct code would be pretty hairy I think (the non-inplace ternary is hairy enough). > > Do you have a use case where this does the wrong thing, or is this > > just a theoretical musing? > > It's a theoretical musing that came out of my attempts > to figure out whether, when one is implementing an > nb_inplace_power slot for a new type, the first argument > is guaranteed to "self". I need to know this so that Pyrex > can do the right thing. > > I've done some experiments with Python code, and it seems > to do the right thing in terms of calling the correct > __pow__, __rpow__ and __ipow__ methods. But I can't tell > from that what's really going on at the typeslot level. > I've looked at the code for the nb_inplace_power of > instance objects (the only example I can find of such > a method!), and it seems to assume that the first > argument is always "self". But I can't see how this is > guaranteed. > > In short, I'm confused! Are you still confused after my assertion above? --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4