PEP 309 (Partial Function Application) Idea

[Chris Perkins]

Random idea of the day: How about having syntax support for
currying/partial function application, like this:

func(..., a, b)
func(a, ..., b)
func(a, b, ...)

That is:
1) Make an Ellipsis literal legal syntax in an argument list.
2) Have the compiler recognize the Ellipsis literal and transform the
function call into a curried/parially applied function.

So the compiler would essentially do something like this:

func(a, ...) ==> curry(func, a)
func(..., a) ==> rightcurry(func, a)
func(a, ..., b) ==> rightcurry(curry(func,a), b)

I haven't though this through much, and I'm sure there are issues, but
I do like the way it looks. The "..." really stands out as saying
"something is omitted here".


Chris Perkins

 

[Steven Bethard]

Random idea of the day: How about having syntax support for
currying/partial function application, like this:

func(..., a, b)
func(a, ..., b)
func(a, b, ...)

That is:
1) Make an Ellipsis literal legal syntax in an argument list.
2) Have the compiler recognize the Ellipsis literal and transform the
function call into a curried/parially applied function.

So the compiler would essentially do something like this:

func(a, ...) ==> curry(func, a)
func(..., a) ==> rightcurry(func, a)
func(a, ..., b) ==> rightcurry(curry(func,a), b)

I haven't though this through much, and I'm sure there are issues, but
I do like the way it looks. The "..." really stands out as saying
"something is omitted here".

Interesting idea, but I have a feeling that it probably won't fly for a
couple of reasons:

(1) The existing use of Ellipsis doesn't have anything to do with your
suggested use. I think people are generally opposed to giving
keywords/symbols in Python two very different meanings. This is one of
the reasons Guido never liked the "a, b, *c = iterable" syntax.

(2) Emphasis recently on python-dev has been away from syntax changes
and towards expansion of the standard library. You would have to make a
_very_ good case that the new syntax is merited.

Generally I do like the idea -- I think a lot of the cases that people
have made for keeping lambda could be discarded with something like
this... But it'd need an extremely well thought out PEP (and an
implementation of course) and even then, I wouldn't get my hopes up.

STeVe

 

[Reinhold Birkenfeld]

Interesting idea, but I have a feeling that it probably won't fly for a
couple of reasons:

(1) The existing use of Ellipsis doesn't have anything to do with your
suggested use. I think people are generally opposed to giving
keywords/symbols in Python two very different meanings. This is one of
the reasons Guido never liked the "a, b, *c = iterable" syntax.

(2) Emphasis recently on python-dev has been away from syntax changes
and towards expansion of the standard library. You would have to make a
_very_ good case that the new syntax is merited.

Generally I do like the idea -- I think a lot of the cases that people
have made for keeping lambda could be discarded with something like
this... But it'd need an extremely well thought out PEP (and an
implementation of course) and even then, I wouldn't get my hopes up.

I like it, and if it helps to convince people that it is okay to get rid
of lambda, perhaps Guido will like it too.

What about proposing it on python-dev?

Reinhold

 

[Scott David Daniels]

The interaction of this with keyword args and omitted args is
problematic (as is the case for rightcurry, in fact). I can't
think of a good way to explain what _should_ happen for a
function defined as def function(*args, **kwargs): ... when you:

def fun(bug, frog, verb): ...
f1 = function(1, ..., frog=3)
f2 = f1(..., 4)
f2()

Keywords were why I did no rightcurry definition in the first place;
I couldn't convince myself there was a good, obvious, resolution.

--Scott David Daniels
(e-mail address removed)