On 21 September 2016 at 02:42, Ryan Gonzalez <rym...@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

> Doing something like:
> lambda x, y: myfunc(partial_arg, x, y)
> is more error-prone to changes in myfunc's signature.

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

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


Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
Python-ideas mailing list
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to