Hacker News Reader

Comment by detaro | Hacker News Reader

I'm not sure what you mean by the first half of your comment. Both def and lambda create functions, and quoting from the article "Lambda expressions are just a special syntax for making functions. They can only have one statement in them and they return the result of that statement automatically.".

def binds it to a name at the same time, which is remembered in the object (which AFAIK isn't really used for anything except maybe debugging tools), lambda returns an anonymous one. The resulting object can be passed around in both cases.

View on HN

it's because i am not that deeply familiar with python and the article is not clear itself on this. what is he complaining about then if they are identical in what's returned? is it simply because the REPL returns <lambda> instead of the function name? why does the REPL do this? are they different in some subtle way?

the point was in something like f#, lambda creates a function which can then be bound to a name if you want. if you do so, this is identical to the "normal" function definition because that is really just syntactic sugar for creating lambda functions and then binding it to a name.

Since the objects are identical type, you could set a doc string and a name on a lambda (they're just properties of the object) and see them during program execution/on the REPL, might make sense for generated stuff like classes from an ORM?

> is it simply because the REPL returns <lambda> instead of the function name? why does the REPL do this?

Because lambdas don't have function names.

i know that. in the example, he assigned the lambda to normalize_case.

Sure, but an object doesn't know what variable it is assigned to (and which variable name should it pick if there's multiple).

the def syntax merely sets the name property on the function object too, since it has a name to set available. As said in other comments, nice for interactive use, irrelevant otherwise.

    >>> normalize_case = lambda s: s.casefold()
    >>> normalize_case
    <function <lambda> at 0x034B04B0>
    >>> normalize_case.__qualname__ = "normalize_case"
    >>> normalize_case
    <function normalize_case at 0x034B04B0>

    >>> def normalize_case(s):
	return s.casefold()

    >>> normalize_case
    <function normalize_case at 0x00594420>
    >>> normalize_case.__qualname__
    'normalize_case'

thank you for clarifying exactly what's going on. other than the __qualname__, in what other ways do the two different bindings differ from each other?

however, this still goes in the bucket of why i personally dislike python. this just seems sloppy and overly complicated.

for example, i tested this out myself.

  > test = lambda x : x*x
  > test
  => <function <lambda> at 0x7ff6221d76e0>
  > test.__qualname__
  Traceback (most recent call last):
    File "python", line 1, in <module>
  AttributeError: 'function' object has no attribute '__qualname__'
  > test.__qualname__ = "test"
  > test
  => <function <lambda> at 0x7ff6221d76e0>

so the repl still reports <lambda> instead of test. actually it turns out that even def doesn't seem to set the __qualname__ property, so i don't get the same thing as you (i am using repl.it which apparently uses python 2.7.10). however, using dir(test) showed that there is the func_name property.

  > def test2(x):
  >     return x*x
  > test2.__qualname__
  Traceback (most recent call last):
    File "python", line 1, in <module>
  AttributeError: 'function' object has no attribute '__qualname__'
  > test2.func_name
  => 'test2'
  > test.func_name
  => '<lambda>'

that seems to be the property that the repl reports, as it gets set by the lambda assignment and the def keyword to the function name. (i verified that by altering the func_name property manually.)

yet, somehow, people call python "simple".

FYI, repl.it has Python3, you just need to select Python3 and not Python.

As far as I know, the __qualname__ property was introduced in Python3.3, so obviously you wouldn't see it in any Python 2 version.

Van Rossum in https://python-history.blogspot.com/2009/04/origins-of-pytho... comments that "lambda" was likely the wrong choice for a name, saying "the choice of terminology had many unintended consequences. For instance, users familiar with functional languages expected the semantics of lambda to match that of other languages. As a result, they found Python’s implementation to be sorely lacking in advanced features."

Perhaps it would help if you didn't think of "lambda" as defining a lambda function, but something more prosaic like "defexpr", and that Python doesn't have lambda functions at all?

As to your experiments, you have found one of the many differences between Python 2 and Python 3.

After researching F# for about 10 minutes, perhaps you might think of Python 2 as being like OCaml and Python 3 being like F# - they are two instances of the same language family, with a mutually compatible language subset, but many incompatibilities.

Don't complain about design warts if you're using an old version. Python 2 is just a couple years from end-of-life, and that's after the support guarantee was extended.

i didn't choose python 2.7. it is what i have installed on my work computer because the three projects i have worked on at work that used python were all using python 2.7, and the projects were led by "python people". in a couple cases, it was me who got them to upgrade from 2.6 to at least 2.7, and i have tried communicating to people to use python3 if they insist on python. i wouldn't choose python for a new project unless i had to again help someone else's project.

python's version bifurcation problem is its problem, not mine. the problem exists.

Sure, just like how it's Microsoft's problem that Windows 98 still gets used in a few places.

As you've discovered, the reported property had a different name in python2. The repl doesn't report a property, it asks the object to give a representative string (__repr__() function) and prints that. Other languages wanting to expose something like this would maybe hide it deeper in the interpreter or build it into each tool separately, Python chooses to make everything accessible from the language itself.

You've bitten onto a more or less internal detail (I've TA'ed a bunch of undergrad courses in Python, and it's firmly in the land of things students don't know if they don't discover it on their own) and use that and seemingly quite little grasp of how Python works to argue that it isn't simple, while of course languages you are more familiar with are better.

Modules and functions in Python have a __name__ attribute. If you've used Python for scripts, you've probably written `if __name__ == "__main__":` at some point, which is the module name for executed scripts, whereas imported modules get their proper name.

Similarly, Python basically keeps track of "proper" names for proper functions, but can't/won't do so for lambdas.

Just as in f#, Python's lambdas can be bound to a name. There's no real difference between a def and a lambda. You're complaining about some distinction that doesn't exist. You didn't even try to discover whether it does before complaining about it.

Reply on news.ycombinator.com