Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
python-imphook
Simple and clear import hooks for Python - import anything as if it were a Python module
> On the PEP site, https://www.python.org/dev/peps/ , there're a lot of deadlocked PEPs, some of them a good and better would have been within, than without.
If it's deadlocked, it really _shouldn't_ be added.
> Let's count - 3rd-party patmatching libs for Python exists for 10-15 years. And only now some of those people who did their work as "third parties" came to do it inside mainstream Python.
What's wrong with multiple implementations? Maybe people want different things? Besides the implementations' existence shows that lack of language support isn't something that blocks the use of pattern matching. Also moving it into the language doesn't mean people will work on that one implementation. Haven't you heard that packages go to the standard library to die? Why would it be any different in the python language. Besides I'm sure that the 3rd party libs will continue to be used anyway.
> The core pattern matching support added isn't bad at all. Could have been better. Best is the enemy of good.
> But I'm pragmatic guy, and had to agree that it can be resolved later. The core pattern matching support added isn't bad at all. Could have been better. Best is the enemy of good.
I'm pragmatic too. I understand that I can do everything that this PEP introduces without the change to the language. I also understand that this PEP could continue to be worked on and improved. It's true that best is the enemy of good. I (and obviously many others here) believe that this is _bad_.
> and we're stuck with an inferior Lisp/ML, especially in the scientific sector.
You will love Julia.
Here is some links:
https://julialang.org/blog/2012/02/why-we-created-julia/
Julia: Dynamism and Performance Reconciled by Design (https://dl.acm.org/doi/pdf/10.1145/3276490)
https://opensourc.es/blog/basics-multiple-dispatch/
And when you start finding things that you miss, Julia and the community got you with excellent Metaprogramming support.
https://github.com/thautwarm/MLStyle.jl
https://github.com/MikeInnes/Lazy.jl
https://github.com/jkrumbiegel/Chain.jl
> 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
This is why I'm still enamored with Lisp. One doesn't wait around for the high priests to descent from their lofty towers of much deep pontification and debate with shiny, gold tablets inscribed with how the PEPs may be, on behalf of the plebes. One just adds new language feature themselves, eg. pattern matching[1] and software transactional memory[2].
1. https://github.com/guicho271828/trivia
2. https://github.com/cosmos72/stmx
I’m writing a TypeScript package for pattern matching by using generator functions.
https://github.com/RoyalIcing/yieldpattern
It’s amazing to me how much pattern matching, well, matches how I think. A conditional if statement means I have to explicitly read properties off an object or inspect an array to check for what I want. Whereas pattern matching means asking ‘I want something that looks like this’ and do the work for me.
Take a look at flynt, a tool that can convert older string formatting code to the newer fstring style. I've found it very helpful!
https://github.com/ikamensh/flynt
> This while we have elephants in the room such as packaging. Researching best practices to move away from setup.py right now takes you down a rabbit hole of (excellent) blog posts, and yet you still need a setup.py shim to use editable installs, because the new model simply doesn't yet support this fundamental feature.
You can do editable installs with poetry, I do it every day.
Just run this: \rm -rv dist/; poetry build --format sdist && tar --wildcards -xvf dist/.tar.gz -O '/setup.py' > setup.py && pip3 install --prefix="${HOME}/.local/" --editable .
More details here: https://github.com/python-poetry/poetry/issues/34#issuecomme...
I can only agree. Compared to other languages I find Python increasingly difficult to reason about, mainly due to its dynamicity. If the language complexity increases as well from now on I don't think I will use Python unless absolutely necessary.
Meanwhile, Julia supports pattern matching due to macros: https://github.com/kmsquire/Match.jl
> In C in a GNU environment, I suspect your Glibc backtrace() function won't work very well if the code is compiled with -fomit-frame-pointer.
Actually, backtraces work correctly without explicit framepointers (in a typical GNU environment using ELF+DWARF).
The general concept has existed in DWARF since version 2 in 1992. The mechanism used for this is known as Call Frame Information (CFI)[0][1] — not to be confused with Control Flow Integrity, which is unrelated.
Here's some example libgcc code that evaluates CFI metadata[2]; there's similar logic in the libunwind component of llvm[3].
Burning a register on a frame pointer is a big deal on i386 and somewhat less so on amd64; there are other platforms where the impact is even lower. So, just know that you don't have to include FPs to be able to get stack traces.
If you're interested in how to apply these directives to hand-written assembler routines, there are some nice examples in [0].
[0]: https://www.imperialviolet.org/2017/01/18/cfi.html
[1]: https://sourceware.org/binutils/docs/as/CFI-directives.html
[2]: https://github.com/gcc-mirror/gcc/blob/master/libgcc/unwind-...
[3]: https://github.com/llvm/llvm-project/blob/main/libunwind/src...
For as long as you're a human and belong to category of "people", you can answer that question as good as anyone else. And your answer is ...?
(Just in case my answer is: https://github.com/pfalcon/python-imphook , yet another (but this time unsucky, I swear!) module which allows people to implement macros (among other things)).