אלעזר schrieb am 19.09.2016 um 17:59:

If at all, it should be function.bind(). It was discussed and dropped; I don't remember why, but one problem is that it looks like an in-place modification.

IMHO, the main drawback of that solution is that it only works for functions and not for any other callable in Python. It would introduce an inconsistency without solving the problem in general. Stefan

On Tue, Sep 20, 2016 at 5:01 PM, אלעזר <elazarg@gmail.com> wrote:

But the foo() finds the function to call, so foo.bind() could be made to find it too.

class Demo: def __init__(self): self.bind = 42 def __call__(self): print("I got called!") foo = Demo() You can most certainly call foo(), but foo.bind() will bite you. With a stand-alone function bind(foo), it can use protocols like __call__. ChrisA

On Tue, Sep 20, 2016 at 6:09 PM, אלעזר <elazarg@gmail.com> wrote:

I meant something like making it a "__bind__" (just a strawman suggestion) and do the same lookup as foo() does, and using a (wrong) functional-programming-inspired syntax

foo 5 ()

Such a syntax will have the side benefit of allowing calling print in a similar way to Python2, which people seem to love.

print "hello" ()

Python has a rule that syntax shouldn't look like grit on Tim's screen. In this case, it looks like the *absence of* grit, which is even worse :) You're giving meaning to the abuttal of two tokens, the first of which must be callable but the second can be anything. And it creates the scary situation of giving valid-but-useless meaning to something all too common in Py2 code: print "hello" This would now create a function that, if called, would print "hello", but then abandons it without a second thought. So it'd work in 2.7, fail with an opaque error in 3.3, fail with a more informative error in 3.5, and silently do nothing in 3.7. No thank you! :) ChrisA

(Sorry, answered to one person again. Reposting) I like the bind() idea because it doesn't clutter the builtin namespace. It solves the import problem and feels very natural IMO. The only issue is the name. In my mind, bind() convey the idea you are modifying the function it self, while partial() convey the idea you return new function. It could also be written in C for performances. Le 20/09/2016 à 10:22, אלעזר a écrit :

Yeah I did say it was a strawman :)

On Tue, Sep 20, 2016 at 11:17 AM Chris Angelico <rosuav@gmail.com <mailto:rosuav@gmail.com>> wrote:

On Tue, Sep 20, 2016 at 6:09 PM, אלעזר <elazarg@gmail.com <mailto:elazarg@gmail.com>> wrote: > I meant something like making it a "__bind__" (just a strawman suggestion) > and do the same lookup as foo() does, and using a (wrong) > functional-programming-inspired syntax > > foo 5 () > > Such a syntax will have the side benefit of allowing calling print in a > similar way to Python2, which people seem to love. > > print "hello" () >

Python has a rule that syntax shouldn't look like grit on Tim's screen. In this case, it looks like the *absence of* grit, which is even worse :) You're giving meaning to the abuttal of two tokens, the first of which must be callable but the second can be anything. And it creates the scary situation of giving valid-but-useless meaning to something all too common in Py2 code:

print "hello"

This would now create a function that, if called, would print "hello", but then abandons it without a second thought. So it'd work in 2.7, fail with an opaque error in 3.3, fail with a more informative error in 3.5, and silently do nothing in 3.7. No thank you! :)

ChrisA _______________________________________________ Python-ideas mailing list Python-ideas@python.org <mailto:Python-ideas@python.org> https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

On Tue, Sep 20, 2016 at 09:56:48AM +0000, אלעזר wrote:

foo.__call__.partial() solves most of the problem I think.

There are two problems with that, one obvious and one subtle. The obvious one is that __call__ is a dunder method, which means that accessing it directly from outside of the object's class is a code smell. It's not necessarily *wrong*, but its a bit... smelly. A bit suspicious. Something we should think *very* carefully about before encouraging. The subtle one is that foo.__call__ may not actually be the method that is used when you call foo(). py> class X(object): ... def __call__(self): ... return "from X" ... py> x = X() py> x.__call__ = lambda: "surprise!" py> x() 'from X' py> x.__call__() 'surprise!' -- Steve

On Tue, Sep 20, 2016 at 8:29 AM, אלעזר <elazarg@gmail.com> wrote:

Guido, can you please elaborate?

"What's going on" is usually that the same arguments are going to be passed over and over again, and the programmer wanted to avoid this repetition. The other option is adjusting the function to a predefined interface.

I did a little searching on a large Python code base I have access to, and that's not what I found. The partial calls don't seem to produce code that's in any way clearer than the equivalent use of lambda would. My conclusion is that most people who are, um, partial to partial do so out of a habit (or perhaps a belief that it's more performant), not to make their code clearer. (FWIW I found an order of magnitude more uses of lambda than of partial in the same code base.)

The alternative to partial is writing a closure in the form of a function, that needs to be carefully inspected to verify that it is indeed just a partial application and not something more complex. It has more opportunity for introducing an error. And it's longer and adds distance between related parts of the code.

We seem to have fundamentally different ideas of what sort of code is most readable. The alternative to partial is usually a lambda, and the signature of the lambda helps me understand how it is being called. I don't see how the lambda is longer or creates more distance. There are some exceptions, when the function has a complex signature that should mostly be preserved (and a few other, rare exceptions). But most of the uses of partial that I found had exactly one call site and the call site was not calling a complex signature. A big problem I have reading code that uses partial is that *unless I already know the function being partialed*, the partial() call itself gives me no clue about the signature of that function. So then I have to look for the call site of the partial (what do you call that?) and then in my head I have to combine that with the partial parameters and figure out what is really happening. A lambda would have given me a simple stepping stone. In effect it's a little bit of "typing" right there, showing me the signature that's being called, which is useful for reading the code quickly. Also, I once timed it and could not show that partial was faster. This surprised me but it wa what I measured (in one particular case).

Elazar

בתאריך יום ג׳, 20 בספט' 2016, 18:20, מאת Guido van Rossum ‏< gvanrossum@gmail.com>:

...

I am radically opposed to this proposal. Every time I see a partial application I wonder endlessly about what's going on.

--Guido (mobile) _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

-- --Guido van Rossum (python.org/~guido)

On Sep 20, 2016 10:52 AM, "Guido van Rossum" <gvanrossum@gmail.com> wrote:

On Tue, Sep 20, 2016 at 8:29 AM, אלעזר <elazarg@gmail.com> wrote:

...

*snip* The alternative to partial is writing a closure in the form of a

function, that needs to be carefully inspected to verify that it is indeed just a partial application and not something more complex. It has more opportunity for introducing an error. And it's longer and adds distance between related parts of the code.

We seem to have fundamentally different ideas of what sort of code is

most readable. The alternative to partial is usually a lambda, and the signature of the lambda helps me understand how it is being called. I don't see how the lambda is longer or creates more distance. There are some exceptions, when the function has a complex signature that should mostly be preserved (and a few other, rare exceptions). But most of the uses of partial that I found had exactly one call site and the call site was not calling a complex signature.

A big problem I have reading code that uses partial is that *unless I

already know the function being partialed*, the partial() call itself gives me no clue about the signature of that function. So then I have to look for the call site of the partial (what do you call that?) and then in my head I have to combine that with the partial parameters and figure out what is really happening. A lambda would have given me a simple stepping stone. In effect it's a little bit of "typing" right there, showing me the signature that's being called, which is useful for reading the code quickly. Most often, when I see lambdas used for this, it looks like: lambda *args, **kw: myfunc(partial_arg, *args, **kw) which isn't more readable than just: partial(myfunc, partial_func) Doing something like: lambda x, y: myfunc(partial_arg, x, y) is more error-prone to changes in myfunc's signature. Also, I don't quite understand the readability issue here; all partial is doing is just...err...partializing the function (I should totally patent that phrase). I find it easy to mentally expand it: partial(f, ...) == lambda *args, **kw: f(..., *args, **kw)

Also, I once timed it and could not show that partial was faster. This surprised me but it wa what I measured (in one particular case).

...

Elazar

בתאריך יום ג׳, 20 בספט' 2016, 18:20, מאת Guido van Rossum ‏<

gvanrossum@gmail.com>:

...

...

I am radically opposed to this proposal. Every time I see a partial

application I wonder endlessly about what's going on.

...

--Guido (mobile)

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

-- --Guido van Rossum (python.org/~guido)

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

-- Ryan [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. http://kirbyfan64.github.io/

I find myself "partializing" in ways partial() doesn't support more often than not. E.g. lambda first, third: myfunc(first, 42, third) I think it's good to have partial() in functools, but it's two orders of magnitude less common than things that should be in builtins. On Sep 20, 2016 9:42 AM, "Ryan Gonzalez" <rymg19@gmail.com> wrote:

lambda *args, **kw: myfunc(partial_arg, *args, **kw)

which isn't more readable than just:

partial(myfunc, partial_func)

I actually wrote the book _ Functional Programming in Python_, yet I haven't the foggiest idea how to parse that code. A decorator parameterized buy two instances of the decorator function itself?! I know I could read the implementation and figure out why that works. But I don't want to encourage that code in real use. On Sep 20, 2016 11:17 AM, "Stephan Houben" <stephanh42@gmail.com> wrote:

I must admit I am a bit partial to partial, you can do fun things like this:

...

...

...

from functools import partial @partial(partial, partial) ... def add(x, y): ... return x+y ... add(3)(4) 7

I suppose that isn't exactly going to convince Guide to put it in builtins, though.

Stephan

2016-09-20 19:48 GMT+02:00 David Mertz <mertz@gnosis.cx>:

...

I find myself "partializing" in ways partial() doesn't support more often than not. E.g.

lambda first, third: myfunc(first, 42, third)

I think it's good to have partial() in functools, but it's two orders of magnitude less common than things that should be in builtins.

On Sep 20, 2016 9:42 AM, "Ryan Gonzalez" <rymg19@gmail.com> wrote:

...

lambda *args, **kw: myfunc(partial_arg, *args, **kw)

which isn't more readable than just:

partial(myfunc, partial_func)

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

אלעזר wrote:

@partial(partial, partial(partial, partial)) def add(a, b, c): return a + b + c

For large numbers of arguments, it's much clearer if you write it this way:

...

...

from functools import partial as badger, partial as mushroom @badger(badger, badger(badger, badger(badger, mushroom))) ... def add(a,b,c,d): ... return a+b+c+d ... add(1)(2)(3)(4) 10

-- Greg

On 9/20/2016 11:51 AM, Guido van Rossum wrote:

We seem to have fundamentally different ideas of what sort of code is most readable. The alternative to partial is usually a lambda,

Partial and lambda are different in that partial captures variable values immediately, whereas lambda does not, unless the default argument trick, with its attendant disadvantages, is used. I consider this one reason to chose one or the other. (The greater flexibility of lambda, pointed out by David Mertz, is another.) # Demonstration from functools import partial def f(a): print(a) # lambda fl = [] for i in range(3): fl.append(lambda: f(i)) fl[0]() # 2 - bug flc = [lambda: f(i) for i in range(3)] flc[0]() # 2 - bug flcd = [lambda i=i: f(i) for i in range(3)] flcd[0]() # 0 - correct # partial fp = [] for i in range(3): fp.append(partial(f, i)) fp[0]() # 0 - correct fpc = [partial(f, i) for i in range(3)] fpc[0]() # 0 - correct

and the signature of the lambda helps me understand how it is being called.

The 'i=i' signature is typically left out by beginners creating multiple functions in a loop, leading to one of *the* most frequent of FAQs. https://docs.python.org/3/faq/programming.html#why-do-lambdas-defined-in-a-l... When added 'i=i', better written '_i=i', is misleading, as '_i' is not really a parameter and 'i' is not a replaceable default value, but is supposed to be a fixed value, as with partial. I believe in a previous thread about creating functions in a loop, it was generally agreed that using partial is better. (This alternative has not made it to the FAQ yet, but I thing it should.) I otherwise generally agree with what you wrote. -- Terry Jan Reedy

On Tue, 20 Sep 2016 15:29:36 +0000, אלעזר wrote:

The alternative to partial is writing a closure in the form of a function, that needs to be carefully inspected to verify that it is indeed just a partial application and not something more complex. It has more opportunity for introducing an error. And it's longer and adds distance between related parts of the code.

While I'm not usually one to promote object oriented programming, another Python alternative is a class with a __call__ method; e.g.: class Adder: def __init__(self, addend_one): self.addend_one = addend_one def __call__(self, addend_two): return self.addend_one + addend_two add_5 = Adder(5) print(add_5(4)) I like the way the whole thing is bundled up into a class. Yes, it's more verbose than a lambda expression or a partial function application, but I find it very readable and its intent is usually pretty obvious. Instances are closures in disguise (and they're all just different ways of hiding state of one kind or another).

Folks, There are pros and cons of partial over lambda over classes, and which you prefer may be at least in part a matter of subjective taste. But Guido has spoken that he is virulently against making partial a builtin. It really isn't hard to put "from functools import partial" at the top of your modules. Can we let this thread die a natural death now please? -- Steve