Pattern matching accepted for Python

[Wsj]

Original article found here: Pattern matching accepted for Python [LWN.net]

A lot of early Python's appeal was in its simplicity. I miss that era. Soon Python is going to resemble C++'s bloated feature set where you're not supposed to use parts of the language because "that's the old way of doing things". This already the case with string formatting.

Python is evolving into several different languages. "There should be one-- and preferably only one --obvious way to do it." I'm waiting for a PEP that deprecates PEP 20, "The Zen of Python". It's become more and more clear that the core developers don't follow it all anymore.

What are your thoughts?

After much deliberation, the Python Steering Council is happy to announce
that we have chosen to accept PEP 634, and its companion PEPs 635 and 636,
collectively known as the Pattern Matching PEPs. We acknowledge that
Pattern Matching is an extensive change to Python and that reaching
consensus across the entire community is close to impossible. Different
people have reservations or concerns around different aspects of the
semantics and the syntax (as does the Steering Council). In spite of this,
after much deliberation, reviewing all conversations around these PEPs, as
well as competing proposals and existing poll results, and after several
in-person discussions with the PEP authors, we are confident that Pattern
Matching as specified in PEP 634, et al, will be a great addition to the
Python language.

We also recognize that such a large new feature needs to be accompanied by
comprehensive documentation and specification, both in the tutorial section
of the documentation and in the language reference. We consider that the
presence of such high-quality documentation must be present on the first
release of Python 3.10, and therefore its absence should be considered a
release blocker. We do not consider the PEPs or any possible external
documentation to be sufficient.

At the same time, we’re rejecting PEPs 640 and 642. Both PEPs have received
little support from core developers. PEP 642’s proposed syntax does not
seem like the right way to solve the jagged edges in PEP 634’s syntax,
although the SC understands the desire to improve those aspects of the
Pattern Matching proposal.

Regarding that, we would also like to mention that changes building on top
of PEP 634 (even PEPs 640 and 642 if they now gain support) can still be
submitted via the PEP process for review using the regular channels
(discussions in python-dev or the Discussions on Python.org server),
followed by a formal submission to the Steering Council for consideration,
taking into account that backwards-incompatible changes can only be made
before the feature freeze point of Python 3.10. See PEP 619
(PEP 619 -- Python 3.10 Release Schedule)
for details on the release schedule for Python 3.10.

We know that Pattern Matching has been a challenging feature that has
sparked considerable discussions and design conversations, leading to
several revisions from feedback stemming from the community, core devs, and
the Steering Council. We are very happy to see that the Python developer
community remains passionate and respectful, and we are sure that the
result has benefited a lot because of it.

Congratulations to the PEP(s) authors: Guido, Brandt, Tobias, Daniel,
Talin, and everyone that participated in the discussion and implementation
of this important new feature!

-The Python Steering Council

 

[Batatas]

Depends on your definition of simplicty. Do you mean simplicity as in minimalist or simplicity as of easy?

Cause in Python stuff is simple, as in easy to do stuff and to read.
While in GoLang, stuff is simple, as in minimalist or only one way to solve a problem.

for example, in Python you can already iterate over Lists in multiple ways, but all of them are really easy to implement and understand:

for element in my_list:
    print(element)

# can be done the same ways like

for i in range(len(my_list)):
    print(my_list[i])

# or
[print(x) for x in my_list]

# or

i = 0
while i < len(my_ist):
 print(lst[i])
 i = i+1

As you can see, here you have a for loop with syntatic sugar, you just need use use the keyword "in"


yet in GoLang you only have one way to iterate over lists (aka slices or any other iteratable), which is

//index or element can be ommited using _, so like, "for _, element :=...." would ommit the index
for index, element := range(my_list) {
     fmt.Println(element)
}

notice that also, in GoLang there are no while loops, yet you can still do while loops with

for 1 < 2 {

  fmt.Println("I like potatoes")
}

But, here's the simplicity as in easy:

in GoLang there's no map function (or any other method available for generics, cause there are no generics)

Here's how you would map a list of int (my_list) to a new list (new_list) using a function (my_func()):

So GoLang

var new_list []int
for _, element := range(my_list) {
    new_value := my_func(element) //this could be inside the append function, but would be hard to read
   new_list = append(new_list, new_value)
}

Yet here's the same thing but in Python

new_list = [my_func(x) for x in my_list]

 

[Batatas]

Python is evolving into several different languages. "There should be one-- and preferably only one --obvious way to do it." I'm waiting for a PEP that deprecates PEP 20, "The Zen of Python". It's become more and more clear that the core developers don't follow it all anymore.

This was already wrong from the beginning, you may have multiple ways of solving the same problem in python, but that doesn't mean that it gets harder to read, understand or implement.

Every multiple way of doing stuff in python are really easy to read, understand and implement, so there's no issue on that.
Adding pattern matching and other stuff from functional programming will just make the code more concise and easy.