On Wed, Nov 13, 2013 at 07:13:19PM -0800, Andrew Barnert wrote:
I know this is getting way off topic, but the real problem with doing curried/auto-partial functions in Python isn't the parens, it's the variable arguments. An auto-partial function has to accumulate parameters if it doesn't get enough, execute when it does. (Currying gives you that for free, because it means you only get one argument at a time, but you can do auto-partials without currying.)
I disagree. The real problem is the ambiguity. Given:
y = divmod(x)
did I intend for y to be a partial function, or did I mean to type divmod(x, 3) but mess up? Given how few coders come from a functional programming background, my money is that it's an error.
In languages with static typing, it's easy for the compiler to resolve this: if y is declared as a function object, then I meant for the partial application. If y is declared as an int, then it's an error. But you can't do this in Python.
But to handle a vararg function, you'd need a separate syntax for partializing vs. calling.
We have that. It's called functools.partial :-)
Aside: am I the only one who wishes there was a functools.rpartial, that binds from the right instead of the left?
Using a different operator like  or % or << seems attractive at first, but it can't handle keywords.
You could add a method, so spam._(n=5) returns partial(spam, n=5), but ._ is hideous, and anything meaningful like bind or partial is no longer a shortcut.
And why is this a problem? You read code more often than you type it, and quite frankly, creating partial applications of functions shouldn't be so common in real-world code that it needs to be so concise.
You could use a special argument value, and ... looks perfect, especially as args[-1]: spam('eggs', ...).
You and I have very different ideas about perfection.