Python lambda expressions are real, formal untyped λ-calculus lambda expressions.

They fit the formal definition; they can only represent one python expression, based on variables (free or otherwise) and references to other functions (abstract symbols). Python uses parenthesis in expressions too.

You use them wherever a lambda is more suitable and convenient than a full function definition. The python def functionname(argumentlist): syntax forms a statement; in Python you cannot put statements inside of expressions, only the other way around. A lambda on the other hand, is an expression, so you can use a lambda to insert a callback function inline:

map(lambda x, y: x[y+5], [(mapping1, integerkey1), (mapping2, integerkey2)])

The above example consists only of an expression. The python map() function takes, as its first argument, a callable, which is applied to each and every element in the list given by the second argument. In the above example, using a lambda expression to define that callable is much easier than using a function statement:

def mapcallback(x, y):
    return x[y + 5]

map(mapcallback, [(mapping1, integerkey1), (mapping2, integerkey2)])

For the full function syntax I need to assign a name, put the function definition on separate lines, and use the return statement to return the result of the expression.

Let me offer some perspective on why we added this feature to the language, when clearly we didn't strictly need to (all methods refs can be expressed as lambdas).

Note that there isn't any right answer. Anyone who says "always use a method ref instead of a lambda" or "always use a lambda instead of a method ref" should be ignored.

This question is very similar in spirit to "when should I use a named class vs an anonymous class"? And the answer is the same: when you find it more readable. There are certainly cases that are definitely one or definitely the other, but there's a host of grey in the middle, and judgment must be used.

The theory behind method refs is simple: names matter. If a method has a name, then referring to it by name, rather than by an imperative bag of code that ultimately just turns around and invokes it, is often (but not always!) more clear and readable.

The arguments about performance or about counting characters are mostly red herrings, and you should ignore them. The goal is writing code that is crystal clear what it does. Very often (but not always!) method refs win on this metric, so we included them as an option, to be used in those cases.

A key consideration about whether method refs clarify or obfuscate intent is whether it is obvious from context what is the shape of the function being represented. In some cases (e.g., map(Person::getLastName), it's quite clear from the context that a function that maps one thing to another is required, and in cases like this, method references shine. In others, using a method ref requires the reader to wonder about what kind of function is being described; this is a warning sign that a lambda might be more readable, even if it is longer.

Finally, what we've found is that most people at first steer away from method refs because they feel even newer and weirder than lambdas, and so initially find them "less readable", but over time, when they get used to the syntax, generally change their behavior and gravitate towards method references when they can. So be aware that your own subjective initial "less readable" reaction almost certainly entails some aspect of familiarity bias, and you should give yourself a chance to get comfortable with both before rendering a stylistic opinion.

Your variables hour and minute change before the lambda is called.

hour = 1
minute = 30

# the values of `hour` and `minute` right now are irrelevant
t1 = Test(lambda x: x.replace(hour=hour, minute=minute))

hour=2
minute=30

# the values of `hour` and `minute` right now are irrelevant
t2 = Test(lambda x: x.replace(hour=hour, minute=minute))

# the values of `hour` and `minute` RIGHT NOW are relevant
# and RIGHT NOW they are 2 and 30, respectively
print(t1.getDate())
print(t2.getDate())

The lambda references the variables, it does not copy their values. In other words, the values at the time of execution of the lambda functions are used, not the values at the time of setting them up.

Your options:

• Hard-code the values in the lambda:

  t1 = Test(lambda x: x.replace(hour=1, minute=30))
  

• Change the order of execution. Call the lambda before you change the values of hour and minute.

  hour1 = 1
  minute1 = 30
  
  t1 = Test(lambda x: x.replace(hour=hour, minute=minute))
  print(t1.getDate())
  
  hour1 = 2
  minute1 = 30
  

• Use different variable names for each lambda.

  hour1 = 1
  minute1 = 30
  
  t1 = Test(lambda x: x.replace(hour=hour1, minute=minute1))
  print(t1.getDate())
  

• Use different scopes to avoid that the lambdas reference the same hour and minute, e.g. by using a function. Essentially that's like using different variable names.

  def helper_function(hour, minute)
      return Test(lambda x: x.replace(hour=hour, minute=minute))
  
  t1 = helper_function(1, 30)
  t2 = helper_function(2, 30)
  
  print(t1.getDate())
  print(t2.getDate())
  

Using different scopes probably is the most elegant approach.

The word "lambda" or "lambda expressions" most often refers to anonymous functions. So in that sense a lambda is a kind of function, but not every function is a lambda (i.e. named functions aren't usually referred to as lambdas). Depending on the language, anonymous functions are often implemented differently than named functions (particularly in languages where anonymous functions are closures and named functions are not), so referring to them with different terms can make sense.

The difference between scheme's lambda keyword and Javascript's function keyword is that the latter can be used to create both anonymous functions and named functions while the former only creates anonymous functions (and you'd use define to create named functions).

The lambda calculus is a minimal programming language/mathematical model of computation, which uses functions as its only "data structure". In the lamdba calculus the lambda-symbol is used to create (anonymous) functions. This is where the usage of the term "lambda" in other languages comes from.