I use a nested function to find matches from a list:

def get_exact(data, key, match):
    def is_match(item):
        if (key in item) and (item[key].lower() == match.lower()):
            return item
        return False
    return [i for i in data if is_match(i)]

No other calls in the project have a need to use is_match(item), so why declare it separately?

However, I will say that, for my example, declaring is_match() outside of get_exact() does run around ~0.04 seconds faster in 10,000 iterations.

def is_match(item, key, match):
    if (key in item) and (item[key].lower() == match.lower()):
        return item
    return False

def get_exact(data, key, match):
    return [i for i in data if is_match(i, key, match)]

The concept underlying your question is so important I feel it needs another answer rather than just a comment (as I had started to do).

The other 3 answers thus far provide some useful points of consideration on whether a given situation merits using what you call "nested function calls". But perhaps a more important point is hidden in the comments under your question: in case you missed the subtlety in what those erudite folks are suggesting, Carl, you have discovered for yourself the topic actually called functional programming. If you have never seen the term, you might not have thought it was really a "thing" in @HighPerformanceMark's comment.

But indeed it is! Functional programming has been written about for decades, since John Hughes' seminal paper Why Functional Programming Matters. There are some languages that are functional languages (i.e. they only let you write in a functional programming style), languages like Erlang, Lisp, OCaml, or Haskell. But there are many more languages that are hybrid imperative/functional languages. That is, they are traditionally imperative languages but offer some support for functional programming as well, including Perl, C++, Java, C#, and many more. Wikipedia's entry on functional programming provides a nice section showing a comparison of functional style vs. imperative style for a number of languages.

There is much to say on the differences between imperative and functional styles, but the key starting point is that with functional programming, functions or methods have no side effects, making it in general easier to both understand and debug programs.

For further reading, you might also take a look at Reginald Braithwaite's Why "Why Functional Programming Matters" Matters and another interesting post here on SO, Why functional languages?

I typically only use inner functions if I'm trying to do something functional that is easier to read when leveraging the closure. For example, maybe I have a function Y that splits a list into two lists of things bigger and smaller than n, respectively. A helper function X that accumulates a tuple composed of those two lists may be a good angle to take, but it could be seen as redundant to pass the same value for n to recursive calls of X, and X is not particularly useful in any other context since it is so specialized. In that case, especially if the X used multiple times inside of Y, making a lambda a less clear choice, I may decide to nest functions.

Note that this is coming from somebody with more of a functional programming background (OCaml, Idris) when it comes to nested functions, so there may be some more Python-specific considerations as well.

You don't really gain much by doing this, in fact it slows method_a down because it'll define and recompile the other function every time it's called. Given that, it would probably be better to just prefix the function name with underscore to indicate it's a private method -- i.e. _method_b.

I suppose you might want to do this if the nested function's definition varied each time for some reason, but that may indicate a flaw in your design. That said, there is a valid reason to do this to allow the nested function to use arguments that were passed to the outer function but not explicitly passed on to them, which sometimes occurs when writing function decorators, for example. It's what is being shown in the accepted answer although a decorator is not being defined or used.

Update:

Here's proof that nesting them is slower (using Python 3.6.1), although admittedly not by much in this trivial case:

setup = """
class Test(object):
    def separate(self, arg):
        some_data = self._method_b(arg)

    def _method_b(self, arg):
        return arg+1

    def nested(self, arg):

        def method_b2(self, arg):
            return arg+1

        some_data = method_b2(self, arg)

obj = Test()
"""
from timeit import Timer
print(min(Timer(stmt='obj.separate(42)', setup=setup).repeat()))  # -> 0.24479823284461724
print(min(Timer(stmt='obj.nested(42)', setup=setup).repeat()))    # -> 0.26553459700452575

Note I added some self arguments to your sample functions to make them more like real methods (although method_b2 still isn't technically a method of the Test class). Also the nested function is actually called in that version, unlike yours.

TL;DR: Use function nesting when you need the characteristics of function nesting

Function Nesting Use Cases (mostly functional idioms, almost certainly incomplete since it's off the top of my head):

• closures
• function factory (programmatic function creation based on parameters)
• creating functions by calling functool.partial
• creating functions by using lambda
• any other reasons you need to create functions during call time

Trade-offs:

• functions are strongly coupled
• the code is always called (unless it's in an if block)
• additional code complexity
• additional runtime cost (potentially, because the inner function get's re-defined with every call to the outer function)
• much harder to extend
• much harder to introspect on the inner function defintion