__rcall__???

[David C. Ullrich]

Tim Peters wrote:

> [Tim]
> [...]I don't grasp what's eating you.
>
> [...] sorry for the aggravation.
>
> > [[Dave]a rant about single-argument vs multiple-argument functions]
>
> My favorite non-Python language is Haskell, in which all functions are
> curried (common jargon in the functional-language biz for "single
> argument"), even addition (e.g. "+" is a function that takes (say) an
> integer argument and returns a function mapping ints to ints; "- 1" is a
> function that returns a function that subtracts one from its argument; "1 -"
> is function that returns a function that subtracts its argument *from* 1;
> etc.).
>
> You don't need to convince me that's an elegant & very useful view of the
> world.  It's simply not Python's view of the world.
>
> Still, as you discovered, it's quite possible to write Python code to fake
> it!  Python doesn't force you to write multiple-argument functions, and I'm
> not even asking you to.  My only interest here is in preventing a push for
> *Python's* call implementation to treat single-argument functions in a
> distinguished way (as would the hypothetical __rcall__ method of the subject
> line); my attempts to explain why that's unnatural in *Python* appear to be
> perceived as attacks against Mathematical Truth.  They're not.  Curried
> functions in Python are as much a strain as representing ints as lambda
> compositions in Python (which also can-- for that matter, has --been done).
>
> [still in sarcasm mode]
> > the idea that different answers are appropriate in different
> > contexts is just silly.
>
> What would be silly is the notion that a single programming language *can*
> (let alone "should") support all modes of expression with equal fluidity.

    Right. I guess there was a minsunderstanding here. The aggravation
was due to my impression that you were saying that just because
Python did this and that it was wrong for me to do something else.
It's clear (today) that that's not what you intended. The reason I took
your comments that way is that I didn't know how else to take them;
the idea that you were just trying to prevent a push for various
changes in Python didn't occur to me (largely because of the
_many_ times I'd said that I wasn't proposing any changes to
Python.)

> choices-have-consequences-and-python-made-some-ly y'rs  - tim

    Indeed. I think they made some real good ones. I actually haven't
said anything to the contrary.

Dunno-why-I'm-posting-this-since-the-world-ends-at-midnight-ly,

DU