While lambda are a great tools that can do the job of partial, partial is always a superior solution when trying to curry a Python function because it's explicit and easier to debug. Having to import it everytime means I usually go for a lambda out of lazyness, but also means that most people don't know about it. If think having it in the builtins would promote cleaner, faster code, but would also facilitate and encourage coding patterns using curried functions.
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. Personally I think that higher order programming should not be encouraged (as opposed to functional programming), and from the lambda syntax I understand it isn't. Elazar בתאריך יום ב׳, 19 בספט' 2016, 18:24, מאת Michel Desmoulin < desmoulinmichel@gmail.com>:
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 10:54 AM Chris Angelico <rosuav@gmail.com> wrote:
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" () This strawman proposal has many downsides I guess. My point being, this can be made to work, but it's probably not worth it. Elazar
On Tue, Sep 20, 2016 at 6:09 PM, אלעזר <elazarg@gmail.com> wrote:
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 :
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
Hi all, I would like to add that I don't believe that discoverability is always better in the `builtins' module. I personally had the experience of going over itertools, where I found 'zip_longest', but I couldn't find a 'zip_shortest'. Only after some googling I found out it was called `zip' and it lived in `builtins'. Stephan 2016-09-20 7:23 GMT+02:00 Stefan Behnel <stefan_ml@behnel.de>:
I am radically opposed to this proposal. Every time I see a partial application I wonder endlessly about what's going on. --Guido (mobile)
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. 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. Elazar בתאריך יום ג׳, 20 בספט' 2016, 18:20, מאת Guido van Rossum < gvanrossum@gmail.com>:
On Tue, Sep 20, 2016 at 8:29 AM, אלעזר <elazarg@gmail.com> wrote:
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.)
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).
-- --Guido van Rossum (python.org/~guido)
On Tue, Sep 20, 2016 at 11:51 AM, Guido van Rossum <gvanrossum@gmail.com> wrote:
Also, I once timed it and could not show that partial was faster. This surprised me but it was what I measured (in one particular case).
I did similar timings on several occasions in the past and was also surprised by the results. Lambdas are often faster than equivalent partials. It looks like at least recent versions of Python have ways to optimize calls to pure Python functions that are not available to functions implemented in C or called from C.
On Sep 20, 2016 10:52 AM, "Guido van Rossum" <gvanrossum@gmail.com> wrote:
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)
-- 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:
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:
On 21 September 2016 at 02:42, Ryan Gonzalez <rymg19@gmail.com> wrote:
Most often, when I see lambdas used for this, it looks like:
lambda *args, **kw: myfunc(partial_arg, *args, **kw)
Wrapper functions like that are almost always more readable when written as named functions: def my_modified_func(*args, **kwds): return myfunc(partial_arg, *args, **kwds)
which isn't more readable than just:
partial(myfunc, partial_func)
It's significantly less clear that it's defining a new callable though, especially for folks that have never heard the phrase "higher order function". It sometimes the right answer in particular contexts (hence the availability of functools.partial), but it does immediately raise an additional barrier to entry for future mainteners of that code (not a particularly *high* barrier as these things go, but a barrier nonetheless).
This form of lambda usage is more commonly seen when the lambda is being used to adapt to a particular callback protocol that passes a certain number of positional arguments to the callbacks (think things like "key" arguments to sorting functions, error handlers, event handlers, etc) In those cases, having the lambda definition right there may help the *reader* remember (or learn!) the callback signature. Consider: mylist = sorted(original, key=(lambda item: measure(item, setting=2)) Even if this is the first time you've seen sorted(), and you've never seen measure(), you know immediately the key function takes one parameter, and can probably make a decent guess as to how to change the behaviour of that sorting operation. By contrast: mylist = sorted(original, key=partial(measure, setting=2)) doesn't give you any hint about the signature of the key parameter unless you already know the signature of measure(). While many folks will already recognise the sorted/key combination specifically, the same can't be said for callback parameters in general. Making as few prior assumptions as we can about the reader's prior knowledge without making the code overly verbose is one of the core aspects of enabling correct local reasoning about code, and enabling folks to edit code correctly *without* global awareness of the code base is one of the core skills in learning to write maintainable code :) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
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 Wed, Sep 21, 2016 at 12:04 AM Terry Reedy <tjreedy@udel.edu> wrote:
I just wanted to point out that the greater flexibility of lambda is a very good reason *not* to choose it: more flexibility implies being harder to reason about. I recommend reading this article about "Principle of Least Power" http://www.lihaoyi.com/post/StrategicScalaStylePrincipleofLeastPower.html Elazar
On Tue, 20 Sep 2016 15:29:36 +0000, אלעזר wrote:
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).
This class should be put somewhere. If you need it from inside a method, you have to choose where to put it. If it is inside the method, it forces the reader to scan it thoroughly to verify there's no "real" closure there, and it also makes your methods significantly longer. If it is outside the whole class, it might be very far away from your logic, doing a very simple thing that is not needed anywhere else. Elazar On Wed, Sep 21, 2016 at 5:32 AM Dan Sommers <dan@tombstonezero.net> wrote:
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
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. Personally I think that higher order programming should not be encouraged (as opposed to functional programming), and from the lambda syntax I understand it isn't. Elazar בתאריך יום ב׳, 19 בספט' 2016, 18:24, מאת Michel Desmoulin < desmoulinmichel@gmail.com>:
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 10:54 AM Chris Angelico <rosuav@gmail.com> wrote:
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" () This strawman proposal has many downsides I guess. My point being, this can be made to work, but it's probably not worth it. Elazar
On Tue, Sep 20, 2016 at 6:09 PM, אלעזר <elazarg@gmail.com> wrote:
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 :
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
Hi all, I would like to add that I don't believe that discoverability is always better in the `builtins' module. I personally had the experience of going over itertools, where I found 'zip_longest', but I couldn't find a 'zip_shortest'. Only after some googling I found out it was called `zip' and it lived in `builtins'. Stephan 2016-09-20 7:23 GMT+02:00 Stefan Behnel <stefan_ml@behnel.de>:
I am radically opposed to this proposal. Every time I see a partial application I wonder endlessly about what's going on. --Guido (mobile)
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. 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. Elazar בתאריך יום ג׳, 20 בספט' 2016, 18:20, מאת Guido van Rossum < gvanrossum@gmail.com>:
On Tue, Sep 20, 2016 at 8:29 AM, אלעזר <elazarg@gmail.com> wrote:
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.)
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).
-- --Guido van Rossum (python.org/~guido)
On Tue, Sep 20, 2016 at 11:51 AM, Guido van Rossum <gvanrossum@gmail.com> wrote:
Also, I once timed it and could not show that partial was faster. This surprised me but it was what I measured (in one particular case).
I did similar timings on several occasions in the past and was also surprised by the results. Lambdas are often faster than equivalent partials. It looks like at least recent versions of Python have ways to optimize calls to pure Python functions that are not available to functions implemented in C or called from C.
On Sep 20, 2016 10:52 AM, "Guido van Rossum" <gvanrossum@gmail.com> wrote:
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)
-- 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:
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:
On 21 September 2016 at 02:42, Ryan Gonzalez <rymg19@gmail.com> wrote:
Most often, when I see lambdas used for this, it looks like:
lambda *args, **kw: myfunc(partial_arg, *args, **kw)
Wrapper functions like that are almost always more readable when written as named functions: def my_modified_func(*args, **kwds): return myfunc(partial_arg, *args, **kwds)
which isn't more readable than just:
partial(myfunc, partial_func)
It's significantly less clear that it's defining a new callable though, especially for folks that have never heard the phrase "higher order function". It sometimes the right answer in particular contexts (hence the availability of functools.partial), but it does immediately raise an additional barrier to entry for future mainteners of that code (not a particularly *high* barrier as these things go, but a barrier nonetheless).
This form of lambda usage is more commonly seen when the lambda is being used to adapt to a particular callback protocol that passes a certain number of positional arguments to the callbacks (think things like "key" arguments to sorting functions, error handlers, event handlers, etc) In those cases, having the lambda definition right there may help the *reader* remember (or learn!) the callback signature. Consider: mylist = sorted(original, key=(lambda item: measure(item, setting=2)) Even if this is the first time you've seen sorted(), and you've never seen measure(), you know immediately the key function takes one parameter, and can probably make a decent guess as to how to change the behaviour of that sorting operation. By contrast: mylist = sorted(original, key=partial(measure, setting=2)) doesn't give you any hint about the signature of the key parameter unless you already know the signature of measure(). While many folks will already recognise the sorted/key combination specifically, the same can't be said for callback parameters in general. Making as few prior assumptions as we can about the reader's prior knowledge without making the code overly verbose is one of the core aspects of enabling correct local reasoning about code, and enabling folks to edit code correctly *without* global awareness of the code base is one of the core skills in learning to write maintainable code :) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
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 Wed, Sep 21, 2016 at 12:04 AM Terry Reedy <tjreedy@udel.edu> wrote:
I just wanted to point out that the greater flexibility of lambda is a very good reason *not* to choose it: more flexibility implies being harder to reason about. I recommend reading this article about "Principle of Least Power" http://www.lihaoyi.com/post/StrategicScalaStylePrincipleofLeastPower.html Elazar
On Tue, 20 Sep 2016 15:29:36 +0000, אלעזר wrote:
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).
This class should be put somewhere. If you need it from inside a method, you have to choose where to put it. If it is inside the method, it forces the reader to scan it thoroughly to verify there's no "real" closure there, and it also makes your methods significantly longer. If it is outside the whole class, it might be very far away from your logic, doing a very simple thing that is not needed anywhere else. Elazar On Wed, Sep 21, 2016 at 5:32 AM Dan Sommers <dan@tombstonezero.net> wrote:
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
participants (15)
-
Alexander Belopolsky -
Chris Angelico -
Dan Sommers -
David Mertz -
Greg Ewing -
Guido van Rossum -
Jonathan Slenders -
Michel Desmoulin -
Nick Coghlan -
Ryan Gonzalez -
Stefan Behnel -
Stephan Houben -
Steven D'Aprano -
Terry Reedy -
אלעזר