That walrus operator has given me exactly what I wanted from C. Although I'd have preferred:
if val = expr():
What's Coming in Python 3.8
381–390 of 558 posts
Re: What's Coming in Python 3.8
#382Python looks more and more foreign with each release. I'm not sure what happened after 3.3 but it seems like the whole philosophy of "pythonic", emphasizing simplicity, readability and "only one straightforward way to do it" is rapidly disappearing.
Beyond the older-than-35 reason, I think a lot of folks are used to the rate of new features because there was a 5 year period where everyone was on 2.7 while the new stuff landed in 3.x, and 3.x wasn't ready for deployment.
In reality, the 2.x releases had a lot of significant changes. Of the top of my head, context managers, a new OOP/multiple inheritance model, and division operator changes, and lots of new modules.
It sucks that one's language is on the upgrade treadmill like everything else, but language design is hard, and we keep coming up with new cool things to put in it.
I don't know about Python 3.8, but Python 3.7 is absolutely amazing. It is the result of 2 decades of slogging along, improving bit by bit, and I hope that continues.
Re: What's Coming in Python 3.8
#383Earlier quoted context omitted.
> If it's okay to end up with the second one of your examples (without the ":=" operator), why did we need to add the walrus operator at all? A couple of reasons: - The walrus eliminates a line of code in the very common scenario where you would prefer not to recalculate (or retype) y(). - The walrus makes it easy to avoid recalculating y() in the less common scenario where you need to avoid doing that. > I don't fin…
>So let me ask you: is the problem you'd like to solve "I want to understand what this code does", is it "I like thinking about English grammar", or is it "I'm too busy to type my own code; that's what my secretary is for"? The problem that has already been solved by every version far , is that it has always stuck to a code of being "pythonic", increasing accessibility, readability, and teachability to wide audiences…
> I would hate to see future generations of programmers suffer just because the current generation apparently can't be arsed to do something like write one single, short extra line of code every now and then.
Every now and then? If you look at the example in the post, you'll see it saving one line of code per branch of the if-elif ladder.
Python code is characteristically tall, and this saves a lot of lines, and it saves them all in exactly the same way.
Re: What's Coming in Python 3.8
#384That walrus operator has given me exactly what I wanted from C. Although I'd have preferred: if val = expr():
That particular version opens the way for massive typo footguns and results in the insanity of defensive programming patterns like yoda expressions.
Re: What's Coming in Python 3.8
#385I long for a language which has a basic featureset, and then "freezes", and no longer adds any more language features. You may continue working on the standard library, optimizing, etc. Just no new language features. In my opinion, someone should be able to learn all of a language in a few days, including every corner case and oddity, and then understand any code. If new language features get added over time, eventua…
The only frozen languages are the ones nobody uses except for play or academic purposes.
As soon as people start using a language, they see ways of improving it.
It isn't unlike spoken languages. Go learn Esperanto if you want to learn something that doesn't change.
Re: What's Coming in Python 3.8
#386Earlier quoted context omitted.
Yeah, a bit of PG’s Arc influence in the wild.
I believe groovy made this popular rather than arc, and it's likely where kotlin's come from, due to being in the java ecosystem.
Most apl deviatives (j, k, q, a) all had implicit arguments for functions that didn't explicitly declare them (up to 3: x, y, and z).
Probably before then too.
Re: What's Coming in Python 3.8
#387Earlier quoted context omitted.
> In a language with less features, you might have to write slightly more code, but the code you write will be more readable to everyone else. I disagree with this, which is precisely why I prefer feature rich languages like Java or better yet Kotlin. It doesn't get much more readable than something like: users.asSequence() .filter { it.lastName.startsWith("S") } .sortedBy { it.lastName } .take(3) Now try writing tha…
Pretty sure the Go community will be fine with not being feature rich, since simplicity, maintainability and getting new people up to speed matter more for them.
The go community have gone to far the other way for me, the endless repetition introduces its own complexity.
Re: What's Coming in Python 3.8
#388Earlier quoted context omitted.
Python is a little more readable, but both Python and Kotlin are perfectly clear in this case: sorted((u for u in users if u.last_name.startswith("S")), key=lambda u: u.last_name )[:3] If last_name is a function, which it often would be in Python, it gets better: sorted((u for u in users if last_name(u).startswith("S")), key=last_name )[:3] However, I think you probably got the sort key wrong if you're taking the fir…
I disagree this python version is as readable and here’s why. It’s about as many characters but more complex. The Kotlin version performs several distinct actions, each being clear to its purpose. These actions have the same syntax (eg requires less parsing effort). The Python version mixes at least 4 different language syntax/features, being list comprehension, if special form in the list comprehension, keywords, an…
I agree. I don't know Kotlin and am reasonably well versed in Python, yet I immediately grasp the Kotlin example as more readable, while having to squint at the Python one for a few seconds. (this is anecdotal of course, and does not account for the example possibly being contrived)
Re: What's Coming in Python 3.8
#389Earlier quoted context omitted.
> In a language with less features, you might have to write slightly more code, but the code you write will be more readable to everyone else. I disagree with this, which is precisely why I prefer feature rich languages like Java or better yet Kotlin. It doesn't get much more readable than something like: users.asSequence() .filter { it.lastName.startsWith("S") } .sortedBy { it.lastName } .take(3) Now try writing tha…
A little off-topic but how does that work? Is 'it' a magic variable referring to the first argument? Never seen magic variables that blend into lambdas like that before... would've expected $1 or something like that.
The idea of anaphoric macros[1] is first found in Paul Graham's "On Lisp"[2] and is based on the linguistic concept of anaphora, an expression whose meaning depends on the meaning of another expression in its context. An anaphor (like "it") is such a referring term.
I think if you like this idea, you will really like the book. Better still, you can download the pdf for free.
[1] https://en.wikipedia.org/wiki/Anaphoric_macro [2] http://www.paulgraham.com/onlisp.html
Re: What's Coming in Python 3.8
#390Earlier quoted context omitted.
>So let me ask you: is the problem you'd like to solve "I want to understand what this code does", is it "I like thinking about English grammar", or is it "I'm too busy to type my own code; that's what my secretary is for"? The problem that has already been solved by every version far , is that it has always stuck to a code of being "pythonic", increasing accessibility, readability, and teachability to wide audiences…
> I would hate to see future generations of programmers suffer just because the current generation apparently can't be arsed to do something like write one single, short extra line of code every now and then. Every now and then? If you look at the example in the post, you'll see it saving one line of code per branch of the if-elif ladder . Python code is characteristically tall, and this saves a lot of lines, and it…
>Every now and then?
Yes, every now and then. The example in this post is an edge case. And even if it wasn't, the walrus operator saved a grand total of three (3!) keystrokes/characters per conditional in the example. "saves a lot of lines" is hyperbole. If the goal of this was saving programmer time or reducing the amount of code, the walrus operator should have been one of the absolute last things in Python to change.
Even just within this HN thread, even the staunchest proponents of this change are admitting that it is only going to be used sparingly, and at best saves a handful of lines of code per project.
If you're seriously telling me that saving a measly three keystrokes is more important to you than maintaining the pythonic philosophy that has made Python successful for decades, I can say nothing else other than that I strongly encourage you to reevaluate your priorities.
edit: I actually did the math wrong. It's only two (2!) keystrokes saved per conditional.