Huh? No pattern matching until now?
One day they’ll all have the complete feature set of scheme
Next big feature in python: expressions!
:laughing:
I’m actually kind of sad about this feature. It lets you shave a few lines of code, but introduces a bunch of foot guns in the process.
this feature in python, or this feature in scheme/racket or this feature in general?
(and which footguns?)
This feature in Python.
There’s a lot of discussion about the feature’s pros and cons in this thread:https://discuss.python.org/t/gauging-sentiment-on-pattern-matching/5770/15\|https://discuss.python.org/t/gauging-sentiment-on-pattern-matching/5770/15
It’s slightly old, but the accepted proposal hasn’t really changed the pro-con landscape much.
My general take is that Python is great as a procedural language with some light features for working with classes and higher order functions. Trying to make it more fully OO or functional is maybe not going to work out any better in Python than it has in any other procedural language that’s tried to do it.
Which is fine. My general take on this sort of thing is, “I like pickles and I like blueberry muffins, but I’m just fine with having them be two separate things and not trying to put both in my mouth at the same time.”
:smile: I like the analogy
I kind of feel the same when I see Haskell code that makes heavy use of the state monad? It’s a cruelty. Haskell doesn’t want to be an imperative language.
Btw - I think that vote illustrates the difference between the Racket and Python crowds perfectly:
how so?
It’s the 44% that votes against pattern matching in all forms.
In Racket due to the module and macro system it is the complete opposite situation. Everyone can experiment with the features they want without worrying about the affect on others.
keep in mind it’s a very small number of votes though :wink:
True.
but yes, in racket/scheme one can develop these dsls as a user
I am still surprised that 44% voted against any form of pattern matching.
I do love myself some pattern matching :wink:
I don’t code in python at all though
I did not vote in this poll, but I would most likely vote against it. Pattern matching seems unpythonic to me. My most-used languages right now are Racket, Haskell, Java, and Python, but I tend to use completely different approaches in each. I’ve noticed that when I write Python with a Scheme (or Haskell) mindset I write bad python so I try to avoid it. I end up clashing with built-in functionality, and everything starts to seem brittle. Python programs written in Racket or Java style also seem less unified to me (for example part of the code is expression based and other parts are statement based. You get a weird mix of prefix and infix operators. Testing becomes brittle for subtle reasons.). I tend to avoid lambda expressions and mocking in python for this reason.
That was a long comment. What I mean to say is that as someone who loves pattern matching but also loves Python, I agree with Sean.
Keep in mind, all that voting came after a very long process of trying to work out how pattern matching would work in Python, and a lot of people in the discussion thread expressed sentiments to the effect of, “I voted no to pattern matching because the process of developing this PEP has convinced me it’s simply not possible to fit this feature cleanly into Python.” Which is a very different sentiment from a knee-jerk “no.”
To what @michaelrauh said, last summer I spent some time with Hy, and ultimately decided to abandon it and port all of my existing Hy code to vanilla Python. For better or for worse, certain ways of working in Python are just more awkward than they’re worth. If that’s proving to be a serious challenge for you, perhaps the project is telling you it wants to be written in a different language entirely?
new office decor, thanks @ben and @spdegabrielle !!
> In Racket due to the module and macro system it is the complete opposite situation. > Everyone can experiment with the features they want without worrying about the affect on others. My impression is that although it’s better to have features in macros than in the language itself, many ways of doing the same thing are a cognitive burden when learning a language and understanding code in it.
For example, Racket has three (IMHO similar) concepts: sequences, streams and generators. That you can define them with macros doesn’t make them any easier to understand.
That’s actually a problem with the language (for me): There are many simple concepts that attract me to Racket, but at the same time there are lots and lots of complicated concepts in the Racket distribution/standard library.
I don’t mean to say it’s impossible to use the standard library, but there’s a lot to learn and it doesn’t exactly feel lean. :smile:
Though, it’s also great how, in Racket, nobody needs to ask permission or engage in some huge political struggle before they can even get started on trying out their idea. In other languages, you can’t have a real go at an idea without hurting somebody somehow, because you basically have to foist it on everybody in a semi-permanent way just to make it available for people to try using.