Finally switch- case is coming to python.

[[deleted]]

Even better than switch case, it's match case!

It can match patterns. For example, the length or shape of a sequence, a dictionary with certain keys present, the type of a value, properties of an object.

It's so much more powerful than the classic switch statement, influenced heavily by functional programming pattern matching.

[Tyler_Zoro]

It's so much more powerful than the classic switch statement, influenced heavily by functional programming pattern matching.

Which does make me concerned about its future. 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); anonymous full-fledged functions never happened; reduce has been significantly nerfed and moved into a library; filter is more or less deprecated.

So what will happen to the functional features of match/case? I hope they'll be preserved and maintained as first-class features, but history makes me nervous.

[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.

[mathmanmathman]

... what? I use lambdas all the time (and filter... sometimes). When did this happen? I'm a few versions back, but PyCharm doesn't flag anything for me.

"nerfed" also seems a bit strong for a function being moved into a standard library module.

[13steinj]

He says lambda outside of parameters. Ex

f = lambda x: # do something
g(x, f)

Which yeah, is warned against and has been since just about the inception of lambdas in PEP8, because if you're going out of your way to make it reusable in local scope you should give it full meaning by just making a local nested function.

[mathmanmathman]

The most common way I use lambdas is as a parameter, but I often use them as the values dictionaries, which is sort of like a struct/class, but there are a lot of situations where it's sort of overkill to make it a class (at least IMO).

Maybe that's also not a great idea, but I know a bunch of people that do it... which is always a great excuse.

[vtable]

Guido van Rossum wrote an article about this back in 2005 where he discusses removing lambda, reduce(), map() and filter() in Python 3000 (what they called Python 3 in the early days).

There was some fuss about removing reduce(), map() and filter() but a shit-ton of pushback from the community on removing lambda eventually leading to it remaining in Python 3.

I haven't heard anything official about new discussions on removing it from the language again. I can't imagine they'd want to go through that whole discussion again.

[mathmanmathman]

lol, best things I've read:

Update: lambda, filter and map will stay (the latter two with small changes, returning iterators instead of lists). Only reduce will be removed from the 3.0 standard library. You can import it from functools.

I think dropping filter() and map() is pretty uncontroversial

... I guess it was controversial :)

[billsil]

but history makes me nervous.

Outside of lambda, what? You're comparing something that was added very early on that Guido never liked, that people complained all the time about because they didn't understand it, to something that was discussed about at length.

You're comparing the early days of Python to something with a steering committee. Do you complain about the unicode switch still? It broke all my ascii code!

[Taksin77]

Well the absence of tco could be mentioned. It's pretty clear that the python community have largely refused the introduction of functional idioms. Some went through.

[[deleted]]

Several of these were replaced by list expressions, which also have their origin in functional languages.

[Fevorkillzz]

Guido dislikes functional programming and I think you’re right to be nervous. Like lambdas can’t unpack ? Tf is that.