__rcall__???

[Tim Peters]

[Tim]
> That is, AFAIK nobody ever asked for it before, and it's not
> screamingly natural (you're not really *surprised* at the lack
> of __rcall__, right?).

[David C. Ullrich]
> No, it doesn't seem screamingly natural, and I'm not really
> surprised at the lack of it. Well, it doesn't seem so natural
> in most contexts; it actually does seem fairly natural (and it
> _is_ very useful, putting-each-bit-of-code-where-it-belongs-
> wise) in this thing I'm doing.

Oh yes!  I appreciate that.  It's the thing you're doing that's unnatural
<wink>.

>     But I wasn't actually expecting anyone to add it to Python for
> me, I just thought I'd ask (mainly because the other day when
> I asked about Transpose it turned out that there _was_ a Transpose
> built in, just spelled funny. Coulda been there _was_ a misspelled
> __rcall__ already there as well. I gather not.)

You gather correctly.

>     What's the story on __rpow__, natural-wise? I have a book that
> lists all the magic methods but leaves out __rpow__. Was that
> just an omission in the book, or did __rpow__ get added some time
> after version 1.3 (the version in the book)?

1.3 predates my reliable memory -- if I'm not mistaken, that's even earlier
than 1.4, which latter not even Guido remembers <wink>.  Section 3.3.6
("Emulating numeric types") of a current Language Reference Manual tells the
full story on __rpow__.

>     If the latter, I'd like to say that when I saw no __rpow__ in
> the book I decided I couldn't do what I was trying to do that day
> (I've got my own clumsy __rcall__ working but I don't know how
> I'd do __rpow__ by hand the same way) - when I found __rpow__
> in the docs I decided that project was doable. It seems clear that
> there's no need for an __rpow__, but I've used it several times.

__rpow__ is clearly needed to implement new "numeric" types, which latter
many people did ask for.  Note that it's a bit of a strain, though:  __pow__
takes an optional 3rd argument, so people can implement their own notion of
modular exponentiation.  It's not clear how to work that option into
__rpow__ too, & I'm not sure the implementation does something sensible if
you try.

IOW, the __rxxx__ methods are clear only to the extent that they're hooking
binary (two-argument) functions.  Calls of the very special form "f(x)" are
important in your app, but in the *general* case

    f(x, y, z, key='howdy', ...)

what the heck is __rcall__ supposed to mean?  You can make something up, but
it won't be compelling; picking on x.__rcall__ is as arbitrary as picking on
y.__rcall__.  The meaning *is* compelling for binary operators, and for that
reason __rgetitem__ would be more "screamingly natural" than __rcall__.

As someone else said, you have a particular kind of multiple dispatch in
mind here (meaning that which function gets called in the end depends on
more than one of the arguments), and Python doesn't have a *general*
approach to that built in.  Your __rcall__ invention looks fine for your
particular version of this problem.

but-likely-not-fine-for-the-next-fellow's-ly y'rs  - tim