←back to thread

PEP 572: Python assignment expressions has been accepted

(groups.google.com)
317 points est | 4 comments | 03 Jul 18 08:30 UTC | HN request time: 0.002s | source
Show context
amelius ◴[03 Jul 18 09:55 UTC] No.17448876[source]▶
If they add anything to Python, it should be the ability to do functional-style programming without hassle. Right now it's almost impossible to compose functions in an inline style such as used in functional programming languages. Yes, there's lambda, but it doesn't extend into multiple lines, and applying a function to a bunch of lambdas directly leads to line-width overflow. Even JavaScript has better support for functional-style programming. Perhaps Guido should spend a year writing Haskell :)
replies(8): >>17448904 #>>17448927 #>>17448972 #>>17449048 #>>17449482 #>>17450517 #>>17450691 #>>17451251 #
icebraining ◴[03 Jul 18 10:00 UTC] No.17448904[source]▶
Python has explicitly discouraged functional-style for a long time, I don't think that's going to change. And frankly, the whole language is quite, I'd even say extremely, mutable; I'm not sure a functional syntax works well with that.
replies(1): >>17449014 #
aib ◴[03 Jul 18 10:28 UTC] No.17449014[source]▶
The problem is, python list comprehensions are very... specific. Add to that the brokenness of if...else and you get a very quirky and specific sublanguage that is hard for outsiders to read. And this is before we take into account the locals/scope/clojure discussion in the link and the PEP (which I frankly did not bother to read.)

On the other hand, you have a concept which translates easily to any language with first-class functions and lambdas. Even the syntax stays the same among languages which use "f(x,y)" for function evaluation and parameter passing.

/* This post is for those occasions when a list comprehension style is advocated over a functional style, which I know was not necessarily what you were doing in your comment. But I think the two points are valid enough on their own. */

replies(1): >>17451033 #
kstrauser ◴[03 Jul 18 15:36 UTC] No.17451033[source]▶
> Add to that the brokenness of if...else

Could you elaborate on that?

replies(1): >>17456653 #
aib ◴[04 Jul 18 11:44 UTC] No.17456653[source]▶
> > Add to that the brokenness of if...else

> Could you elaborate on that?

It's a very opinionated statement on my part. `if COND then TRUE-CASE else FALSE-CASE` is the correct form to use, in my opinion. Python uses `TRUE-CASE if COND else FALSE-CASE`.

replies(1): >>17465074 #
1. hellofunk ◴[05 Jul 18 17:25 UTC] No.17465074{3}[source]▶
Conventional if statements in Python do use your preferred form of `if COND then TRUE-CASE else FALSE-CASE`.

What you are talking about is a different kind of expression, similar to a ternary operator. It is not the same as if...else

replies(1): >>17467465 #
2. aib ◴[05 Jul 18 22:38 UTC] No.17467465[source]▶
The reason it's not the same as if...else is that it's freaking backwards :D
replies(1): >>17469932 #
3. hellofunk ◴[06 Jul 18 08:53 UTC] No.17469932[source]▶
You said:

> Python uses `TRUE-CASE if COND else FALSE-CASE`.

And this is wrong -- this is not how Python if statements work.

replies(1): >>17470775 #
4. aib ◴[06 Jul 18 12:20 UTC] No.17470775{3}[source]▶
> > Python uses `TRUE-CASE if COND else FALSE-CASE`.

> And this is wrong -- this is not how Python if statements work.

Huh? Didn't you yourself say I was not talking about if statements:

> What you are talking about is a different kind of expression, similar to a ternary operator. It is not the same as if...else

In any case, I'm talking about the case that goes `TRUE-CASE if COND else FALSE-CASE`, as can be deduced from my typing `TRUE-CASE if COND else FALSE-CASE`.