Nice lambda. You've defended yourself admirably. Did you know there's an `operator.itemgetter` function that does that?

So that's:

  >>> sorted(((x, -(x**2)) for x in xrange(10) if 0 == x % 2), key=operator.itemgetter(1))
  [(8, -64), (6, -36), (4, -16), (2, -4), (0, 0)]

Do note that good code and code golf are two different things! :D

> Nice lambda. You've defended yourself admirably.

Thanks!

> Did you know there's an `operator.itemgetter` function that does that?

Yes, I'm quite aware! Are you aware the "useless" functional solution with lambda is two characters shorter?

  >>> len('lambda item: item[1]')
  20
  >>> len('operator.itemgetter(1)')
  22

Cause you're apparently not aware that I was demonstrating a use-case for lambdas as one-off functions that are passed to other functions (which is an abstract concept from the particular function used), and you didn't demonstrate how list comprehensions or generators make them not-needed. Of course, that's because it was a leading question and the answer is that the concepts are orthogonal so it cannot be demonstrated.

I bet you two would be good friends IRL.

I'm sure we would. I'll buy the first drink. :D

A more idiomatic way to handle this is to arrange the items in the tuple by sort precedence, then restructure the data in the tuple after the sort.

>>> [(b, a) for a, b in sorted(((-(x2), x) for x in xrange(10) if 0 == x % 2))]

[(8, -64), (6, -36), (4, -16), (2, -4), (0, 0)]

However, ocasionally you still need a more complex sorting function. So lambdas are still handy, IMO.

Now you're moving goalposts...

> Nobody said it cannot be done the way you did it. You were just pointed at the shortcomings of your approach

I "addressed" the shortcomings of "my approach" by showing that Python (the language, not the community) allows you to access and manipulate the data you claimed was important and missing.

I don't believe it is necessary for most simple functions to know what their name is. I do believe the demonstrated code is self documenting enough to not require a documentation string. You made those "requirements". I never claimed that every function must be a lambda - you seem to be implying I am, so I am explicitly stating that I do not.

Here's a place where you really do need a named function (due to deficiencies in Python's lambda implementation):

  >>> def named_lambda(procedure, name, documentation=''):
  ...     procedure.__name__ = '<lambda {}>'.format(name)
  ...     procedure.__doc__ = documentation
  ...     return procedure
  ... 
  >>> absolute_path = named_lambda(lambda path: path if path.startswith('/') else '/' + path, 'absolute_path', 'Return the absolute unix path from a given path name')
  >>> absolute_path.__name__
  '<lambda absolute_path>'
  >>> absolute_path.__doc__
  'Return the absolute unix path from a given path name'

Of course, that's completely silly... since the point of a lambda function generally is that the function is generally small enough and short-lived enough that it does not need a name or documentation.

> the Python community generally prefers stupidly simple, easy to understand solutions.

Which, despite your protests, includes using lambdas!

> Using magic attributes to argue against it just makes it worse - remember this is a thread about idiomatic Python code bases.

How else does a function "know its own name" unless it uses the "magic" attribute "__name__"? Oh, you prefer "func_name"? That's cute:

  >>> named_lambda.func_name
  'named_lambda'
  >>> named_lambda.__name__
  'named_lambda'
  >>> named_lambda.__name__ = 'lol'
  >>> named_lambda.func_name
  'lol'
  >>> named_lambda.func_name = 'named_lambda'
  >>> named_lambda.func_name
  'named_lambda'

So in this comment I am replying to, it is a bad thing that I made use of "__name__", but in the comment THAT was replying to, it was a bad thing that I did NOT use "__name__" or its linked "func_name". That's how you move goal posts!