[Python-Dev] Is PEP 572 really the most effective way to solve the problems it's targeting?

[Mike Miller]

Sorry all, wasn't specific enough.

By "modern" I mean the last decade perhaps.  New languages that have had a 
chance to look at the older generations and choose their best ideas, while 
leaving behind the rest.

Personally I thought of Swift (Ryan mentioned), Kotlin, Rust, and perhaps Go, 
though Go wasn't focused on breaking new ground outside of ease of concurrency. 
I don't know R or Felix at all, but sound interesting.  Nim is another I'm 
vaguely aware of.  They surely have given some thought to the issue.

One thing that jumped out at me is that most replies here jumped to the question 
of whether they supported assignment-expressions, but that is only one potential 
solution.  To be more clear, I wondered how did they solve "the problem itself?" 
  Was their solution different?  Ryan somewhat alluded to that, but I'd like to 
dig in a bit on that part.

In contrast, in many of the other threads I heard, "C, C++, C#, Java, etc do 
assignment-expressions, they're useful and not so hard to learn."  Ok that's 
reasonable, but where is the industry headed?  Python deferred long enough that 
we don't necessarily have to choose a classic solution.

So, it sounds like many of the new generation of languages are not embracing 
these expressions everywhere but rather letting folks do an assignment right in 
the statement where their use case applies, if, while, maybe comprehensions.  Is 
that accurate?

Looks like I've got some homework to do, haha.

-Mike


On 2018-04-26 17:58, Steven D'Aprano wrote:
> What counts as a modern language? Less than five years old? Less than
> fifty years old? Are Javascript, Ruby and R modern? They all support
> assignment as expressions.
> 
> I think Koitlin, Rust and Go prohibit assignment as expressions.
> 
> Swift assignment evaluates as Void (equivalent to None in Python, I
> guess), so you can use assignment in an expression but it returns
> nothing and only operates by side-effect.
> 
> As far as type hints go, I think that if you need explicit type hints in
> the middle of an expression, it's a bad idea and you ought to pull it
> out as a separate statement. That applies regardless of whether that
> expression involves binding or not.