__rcall__???

[David C. Ullrich]

Tim Peters wrote:

> [...]
>
> >     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__.

    Does it? I must be a version behind again or something, "Emulating numeric
types" is 3.3.5 here. Before I spend time trying to catch up: Are you saying
that
the current 3.3.6 tells the full story, including the answer to the question I
asked about the _history_, when __rpow__ was introduced?

>
> >     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,

    Again, does it? A few weeks ago 1.5.2 was the latest version - there the
docs say that __pow__ takes a third argument but the interpreter disagrees.
Well, of course I can make __rpow__ take whatever arguments I like,
but the point is to implement pow, and pow seems to barf on a third
argument:

>>> pow(2,2)
4.0
>>> pow(2,2,2)
Traceback (innermost last):
  File "<stdin>", line 1, in ?
TypeError: 2-sequence, 3-sequence
>>>

This would be the Windows 1.5.2. I read that the next version
would be 1.6 and it wasn't due for a while - am I behind again
or what?

    (Oh. Maybe you're assuming I'm using the prelease 1.6? No,
I'm a weenie.)

> 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__.

    Well, again, I wasn't actually making a request. If you're curious what the
current thing actually _does_ in that situation, the answer is that there are
no Functions that take more than one parameter. (It's supposed to be a
math thing - "officially" there's no such thing as a function of two variables
in mathematics either, "officially" they get emulated by functions of one
variable.)


> 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