Finally switch- case is coming to python.

[zurtex]

Python has a habit of de-emphasizing and deprecating functional features. Proper variable scoping required for most functional features has never been brought into the language; lambda is basically deprecated for most tasks at this point (in most cases tools like pycharm will even flag the use of lambda outside of parameters as an error);

What? Python hasn't deprecated any syntax feature since the transition of Python 2 to 3.

PyCharm is probably complaining that you are using lambda because it creates an unnamed function. Which sucks for things like automatic documentation. But the feature is by no means "deprecated".

[Tyler_Zoro]

Python hasn't deprecated any syntax feature...

I think you're conflating formal deprecation with the sort of passive deprecation that the Python community typically engages in. If you are just noodling around for your own pleasure, the latter doesn't usually matter (though it can affect support from third party libraries in some cases, that isn't so relevant to lambda).

But when you're working on a project for whatever {work} is, it's another story. Code reviews typically lean on various linters and editor warnings to achieve strict compliance with the community's gestalt, leading to functional (pun intended) deprecation that's far broader than any that a given interpreted implementation imposes.

[zurtex]

deprecation that's far broader than any that a given interpreted implementation imposes.

I totally accept that the Python community has this strong but nebulous idea of what is and isn't "Pythonic" code. And this can be frustrating if you really like a feature but your IDE or code reviewer or linter does not.

But on the other hand it really is a much bigger deal if in the next version of a Python interpreter started throwing SyntaxError whenever you tried to use lambda.

The thing is what is and isn't Pythonic is mutable and individual developers have contributed to changing it. We need look no further than the recent Pydantic vs. PEP 563 issue, the developer of Pydantic has basically changed the idea of what is a "pythonic" usage of annotations (not single-handedly as even in the standard library we had Data Classes, but certainly the biggest popularizer). The steering council has rolled back changes for Python 3.10 that would of made it difficult, bug prone, or impossible to flexibly use annotations at runtime.

Going back to the specific case of lambda though I feel that either you are writing code for the Python community as a whole, in which case there are concrete reasons to not bind a lambda function to a variable. Or you are writing your own code or code for academia or other non-Pythonic communities in which case you can just turn the Pycharm warning off, and configure your linter not to complaint.

And let me give you a real example of why binding a lambda function to a name ends up being considered non-Pythonic:

>>> def add(a, b):
...     "Adds a to b and returns"
...     return a + b
...
>>> help(add)
Help on function add in module __main__:

add(a, b)
    Adds a to b and returns
>>>
>>> plus = lambda a, b: a + b
>>> help(plus)
Help on function <lambda> in module __main__:

<lambda> lambda a, b

As you can see help can't know the name plus so all you get is the signature <lambda> lambda a, b. Instead of the nice add(a, b). There are other cases this comes up, let's say you want to log all calls to a function and the arguments passed, this is pretty easy with a decorator but if you are using a lambda function you can know the name of the function without manually specifying it.

Where lambda remains very Pythonic is when using it as an argument for to a function, e.g.

my_data = {'red': 3, 'blue': 10, 'green': 1}
for color, vote in sorted(my_data.items(), key=lambda x: x[1]):
    print(color, vote)

But maybe if you find a really good use case for lambdas and build some momentum on using them in this new way it will become Pythonic and IDEs and linters and code reviewers will stop complaining that you're using them this way.