__rcall__???

[David C. Ullrich]

Tim Peters wrote:

> [David C. Ullrich]
> [...]
> > 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?
>
> No, there's no info in the manual about the history.  Misc/HISTORY (from the
> source distribution) doesn't say anything about rpow either.  If it really
> matters to you when __rpow__ got introduced, you'll have to ask someone at
> CNRI to dig thru old CVS diffs.

    No, it doesn't matter a bit. I was assuming that your reply had at least
_some_ relevance to the question I'd asked - if so there would have to
be information on the history in that section of the docs. I guess I
shouldn't assume things like that<wink>.

> >> ... __pow__ takes an optional 3rd argument,
>
> > Again, does it?

[...]

> I suspect you shot yourself in the foot by doing something like
>
>     from math import *
>
> without admitting to it <wink>.

    Again, thanks for your assistance <wink> - I figured out I
think it was a week or so ago that this was the problem, and
then I "admitted" it right here, in a post that has just fallen
off the local server. Thanks<wink wink>.


> > ... 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.)
>
> This explains why Guido is agonizing over whether Python2 should represent
> integers as nested sets or via lambda composition <wink>.

    I see your point. Probably the answer to a question like "should there
be multi-variable functions or just functions with single arguments?"
is exactly the same for a programming language like Python and for
every possible application written in that langauge - the idea that
different answers are appropriate in different contexts is just silly.
The idea that a person needs to know what the _goal_ is before
determining what methods are appropriate is even sillier. Thanks
for clarifying that. <Wink _this_...>

    Which seems "simpler" to you, the chain rule in "several-variable
calculus", with all those partial derivatives and sums and things,
or the equivalent chain rule in "vector calculus", that just happens
to look exactly the same as the calc-101 chain rule?

    Never mind, there's no calculus at all in out-of-box Python
so there can't be any point to it.

> in-a-language-with-curried-functions-rcall-could-be-natural-ly y'rs
>     - tim