Pattern matching accepted for Python
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."
| From: | Python Steering Council <steering-council-AT-python.org> | |
| To: | Python-Dev <python-dev-AT-python.org> | |
| Subject: | [Python-Dev] Acceptance of Pattern Matching PEPs 634, 635, 636, Rejection of PEPs 640 and 642 | |
| Date: | Mon, 08 Feb 2021 12:07:22 -0800 | |
| Message-ID: | <61D540B9-2FE5-4CC8-8038-5654B1D325C7@python.org> | |
| Cc: | python-committers <python-committers-AT-python.org>, Python Steering Council <steering-council-AT-python.org> | |
| Archive-link: | Article |
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 https://discuss.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 (https://www.python.org/dev/peps/pep-0619/) 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 _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.... Message archived at https://mail.python.org/archives/list/python-dev@python.o... Code of Conduct: http://python.org/psf/codeofconduct/
(Log in to post comments)
Pattern matching accepted for Python
Posted Feb 9, 2021 18:58 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
Which one do people prefer, btw? I'm personally in favor of this one: https://upload.wikimedia.org/wikipedia/commons/6/6c/Stain...
Pattern matching accepted for Python
Posted Feb 9, 2021 19:26 UTC (Tue) by dskoll (subscriber, #1630) [Link]
Clearly this one is more Pythonic.
Pattern matching accepted for Python
Posted Feb 9, 2021 19:27 UTC (Tue) by leromarinvit (subscriber, #56850) [Link]
That doesn't look like a very useful kitchen sink. It seems larger dishes would make a huge mess.Personally, I prefer this classic Mozilla design.
Pattern matching accepted for Python
Posted Feb 10, 2021 16:59 UTC (Wed) by fredrik (subscriber, #232) [Link]
https://bugzilla.mozilla.org/show_bug.cgi?id=122411
At least if you skip the bickering and the folks who had to take the joke just one step too far. You know, almost like an attempt to introduce pattern matching in Python.
Ok, I'll show myself out. Have fun! :)
Pattern matching accepted for Python
Posted Feb 9, 2021 21:35 UTC (Tue) by jamespow (guest, #125052) [Link]
Pattern matching accepted for Python
Posted Feb 9, 2021 22:52 UTC (Tue) by mpr22 (subscriber, #60784) [Link]
Pattern matching accepted for Python
Posted Feb 10, 2021 15:02 UTC (Wed) by mathstuf (subscriber, #69389) [Link]
Pattern matching accepted for Python
Posted Feb 9, 2021 23:18 UTC (Tue) by oak (guest, #2786) [Link]
Pattern matching accepted for Python
Posted Feb 10, 2021 0:11 UTC (Wed) by flewellyn (subscriber, #5047) [Link]
Pattern matching accepted for Python
Posted Feb 10, 2021 15:50 UTC (Wed) by memey (guest, #97182) [Link]
Pattern matching accepted for Python
Posted Feb 10, 2021 1:59 UTC (Wed) by devnull13 (subscriber, #18626) [Link]
Pattern matching accepted for Python
Posted Feb 10, 2021 1:14 UTC (Wed) by linuxrocks123 (subscriber, #34648) [Link]
Pattern matching accepted for Python
Posted Feb 10, 2021 10:58 UTC (Wed) by edomaur (subscriber, #14520) [Link]
Pattern matching accepted for Python
Posted Feb 10, 2021 13:01 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
Pattern matching accepted for Python
Posted Feb 12, 2021 8:08 UTC (Fri) by edomaur (subscriber, #14520) [Link]
Pattern matching accepted for Python
Posted Feb 10, 2021 23:29 UTC (Wed) by ofranja (subscriber, #11084) [Link]
Pattern matching accepted for Python
Posted Feb 12, 2021 8:12 UTC (Fri) by edomaur (subscriber, #14520) [Link]
So, my combo, Python+Mypy and Rust, and I'm mostly happy. Oh, and I do a bunch of Bash sorcery too...
Pattern matching accepted for Python
Posted Feb 10, 2021 11:58 UTC (Wed) by lobachevsky (subscriber, #121871) [Link]
Pattern matching accepted for Python
Posted Feb 10, 2021 14:19 UTC (Wed) by pepoluan (guest, #144746) [Link]
That said, if you don't like it, you don't *have* to use it. Plus it will only be available starting Python 3.10 anyways.
Pattern matching accepted for Python
Posted Feb 10, 2021 14:19 UTC (Wed) by hater_slash_lover (guest, #144755) [Link]
Pattern matching accepted for Python
Posted Feb 11, 2021 0:20 UTC (Thu) by HelloWorld (guest, #56129) [Link]
He really is that childish.
Pattern matching accepted for Python
Posted Feb 12, 2021 3:12 UTC (Fri) by linuxrocks123 (subscriber, #34648) [Link]
Not kidding.
> because it doesn't have functionality *that you don't have to use* seems... silly to say the least.
Even if I chose not to use this language feature in my own code, it would show up in Google results and StackOverflow and stuff if I wanted to look things up, so I'd have to learn it eventually. Being on Python 2, I already understand the language entirely, and it won't change, so I can forever continue to get appropriate search results and sample code for anything I want by specifying the Python version in my search query, or else by filtering out all search results from after the release Python 3, and I can be secure in the knowledge that I will fully understand the code that I find.
The reason I'm not moving to 3 isn't because of this new feature, of course, but it's nice to watch from the sidelines as the Python core team does even more stuff I don't want to have to deal with, and to know that I don't have to deal with it.
> Choosing to use unsupported, unsafe version of python...
The hell? "Unsafe"? Python is a scripting language. It doesn't have anything even resembling pointers. It's safe. As far as "unsupported", the Python interpreter is written in C. You can take C code from 1980 and have a decent shot at having it work unmodified; if it doesn't work, it's always obvious what needs to be changed and always simple to make the change. If no one else "supports" Python 2, I will. I expect the first work I'll have to do to "support" it will be 15 years from now when I have to decide whether to add an explicit cast to a file or to use -fpermissive. Truly back-breaking work.
Pattern matching accepted for Python
Posted Feb 12, 2021 13:19 UTC (Fri) by calumapplepie (subscriber, #143655) [Link]
But don't take my word for it. Lets talk in 18 years, when QT 5 is removed from distributions (along with the versions of every other library that have working bindings), a new technique for exploiting the C code that makes up Python is discovered, and Year 2038 bugs have popped up in both Python and its dependencies.
Code ages, and that aging will produce unexpected bugs and headaches. It's probably best to start upgrading now, rather than wait indefinitely and be faced with a massive wall of work later.
Pattern matching accepted for Python
Posted Feb 12, 2021 14:06 UTC (Fri) by mathstuf (subscriber, #69389) [Link]
> It's probably best to start upgrading now, rather than wait indefinitely and be faced with a massive wall of work later.
"Yeah, but that's a problem for future me; present me is happy with the status quo." (I've heard and used this story for various things; it's almost never a good plan IME.)
The upgrade doesn't have to be to Python3 either. Perl, Ruby, whatever.
Pattern matching accepted for Python
Posted Feb 12, 2021 23:34 UTC (Fri) by Wol (subscriber, #4433) [Link]
FORTRAN and Fortran77 don't have pointers, as far as I know (which is why I rarely use pointers in C :-). Yet buffer overflows are still easy to commit - iirc the language spec explicitly disables array bounds-checks by default.
Cheers,
Wol
Pattern matching accepted for Python
Posted Feb 13, 2021 0:32 UTC (Sat) by linuxrocks123 (subscriber, #34648) [Link]
- The only one of those CVEs that's really concerning is a buffer overflow in a socket library, and even that was in a pretty obscure library function. It's rather hard, in general, to have exploitable bugs in a language interpreter, since, if someone can run code in the interpreter, that person is usually trusted. JavaScript is the exception, which is why JavaScript has historically been a security nightmare.
- 2038 is not related to Python or Python versions in the slightest. I use FLTK, not QT, for my Python GUI needs, and FLTK is a nice, stable, minimal, C++ codebase, easily to compile from source if someone drops it from my distro, and I'm on Slackware, so I compile lots of stuff from source anyway (though SlackOnly is pretty nice for not having to).
- TLS version is controlled by the linked OpenSSL library, not by the Python interpreter. Work will only be necessary after they have an ABI breakage, which will also affect lots of other software linked to the library, stop supporting the old branch, which will take longer still, and servers on the Internet drop support for whatever the last supported protocol version is in the last version of OpenSSL 1.1.x. I doubt that last part will ever happen, period, unless there's a repeat of POODLE. If it does, the work I will need to do will consist of wrapping one C API to call functions in another similar but not identical C API. Not that hard.
I don't have to move if I don't want to, and neither does anyone else who maintains sufficient control over his environment.
Pattern matching accepted for Python
Posted Feb 14, 2021 16:44 UTC (Sun) by nix (subscriber, #2304) [Link]
Java in the browser, now thankfully extinct, was the other one -- and it was even worse because keeping your sandboxed code from somehow gaining access to ClassLoaders which *by design* could load and execute arbitrary code was really rather difficult.
Pattern matching accepted for Python
Posted Feb 19, 2021 4:01 UTC (Fri) by flussence (subscriber, #85566) [Link]
URLs are arguably the worst language ever invented - in the past they've been abused for running system commands, popping telnet windows, circumventing script-running controls via XBL bindings, portscanning and request smuggling on the local network and the like. Even nowadays it's still a full-time effort to interpret well-formed ones for the sake of enforcing cross-domain security boundaries correctly, and that's just client-side! Probably the highest ratio of risk per byte of anything, and nigh impossible to replace. AOL may have had a point.
Pattern matching accepted for Python
Posted Feb 10, 2021 11:30 UTC (Wed) by kragil (guest, #34373) [Link]
I don't get why they go into this direktion, I don't wanna know how much CO2 is released because the world runs on utterly slow Python code for decades now.
They could have built a good compiler for type annotated Python that makes things much much faster. That would be nice in a cloud world, where you pay for everything, but what do we get?
Bolted on and ugly pattern matching.
The human existence is hopeless, I guess.
Pattern matching accepted for Python
Posted Feb 10, 2021 13:49 UTC (Wed) by fermigier (guest, #12330) [Link]
Pattern matching accepted for Python
Posted Feb 10, 2021 16:51 UTC (Wed) by kragil (guest, #34373) [Link]
Will static typing make my programs run faster?
Mypy only does static type checking and it does not improve performance.
Pattern matching accepted for Python
Posted Feb 10, 2021 17:13 UTC (Wed) by antoinealb (subscriber, #124877) [Link]
Pattern matching accepted for Python
Posted Feb 12, 2021 8:14 UTC (Fri) by edomaur (subscriber, #14520) [Link]
Pattern matching accepted for Python
Posted Feb 10, 2021 22:55 UTC (Wed) by NYKevin (subscriber, #129325) [Link]
* You don't particularly care about supporting "standard" Python annotations, and are fine with using a non-standard syntax instead.
* You want to be able to selectively annotate the bits of the module which are actually bottlenecks (as determined by profiling), and leave everything else dynamically typed.
* You want something that already works, is stable, and shows promising benchmark numbers.
Then you can use https://cython.org/ instead. Cython actually predates the whole Python annotation system altogether, so at this point, I would tend to assume it's quite stable and mature. But I don't currently maintain code that uses it, so I could be wrong about that.
Pattern matching accepted for Python
Posted Feb 10, 2021 21:56 UTC (Wed) by timrichardson (subscriber, #72836) [Link]
Although I think this is going to be a very confusing name ("That's Dikkens with two Ks, the well-known Dutch author").
Pattern matching accepted for Python
Posted Feb 17, 2021 18:48 UTC (Wed) by tao (subscriber, #17563) [Link]
Pattern matching accepted for Python
Posted Feb 10, 2021 17:58 UTC (Wed) by gregormendel (guest, #144764) [Link]
It seems very fashionable here to be resistant to change and improvement...and apparently security patches?? If the only way to be cool is to refrain from using functionality available in every other popular language, I'm fine being uncool.
Pattern matching accepted for Python
Posted Feb 10, 2021 17:58 UTC (Wed) by Taliesyn (guest, #144765) [Link]