[Python-ideas] A suggestion for Python 3 vs Python 2

[Steven D'Aprano]

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.


-- 
Steven