Python 3.8.0a1 is now available for testing

I agree with you.

It's very exciting to remove these sorts of redundant lines, but I cannot train my brain to intuitively view that line as it will be interpreted.

There is one case where the benefit, IMHO, far outweighs the negatives, and that can be seen in slides 30-31 of Dustin Ingram's slideshow[1].

PEP 572... the day Python jumped the walrus.

1. https://speakerdeck.com/di_codes/pep-572-the-walrus-operator...

This feels very Perl-y in the example given, in that it requires that you know what yet another operator means to read code that uses it. Since Python is supposed to be “executable pseudocode” (roughly), this kind of new operator might increase the amount of learning that a beginner has to do to read others’ code. I hope that this decision does not pave the way for more like it, because it would make Python code much less readable to someone who hasn’t studied the new operators yet.

"readability" is such a crap excuse for or against things. Everything is unreadable until you learn to read it. Reading is simply a mapping of what you see, to internalized meaning.

Even if you accept that there is some continuum of "...ability" of these things, it's completely arbitrary and unique to everyone as to where the line between "this should be in" and "this should be out" lies.

Whatever else the walrus operator is, it isn't "post-Guido Python". Guido was one of the authors of PEP 572, pushed for its acceptance, and was still BDFL when it was officially accepted into Python (by Guido).

You have causality backwards. The vitriolic backlash to this change is part of why Guido stepped back from Python...

This statement returns a syntax error. But I get what you mean. For

  if (a := 1) or (b := 1):
    print(locals())

since a is truthy, it gets bound and is in scope, whereas b is not, which makes sense to me.

I believe or has higher precedence than := in this case thus the syntax error. Wrapping := in parentheses, like the other commenter suggested, resolves the issue.

To understand that you need to understand “if”, “or” and assignment expressions. You think this is hard to understand, and that’s fair, but the hard point here isn’t the assignment expression, it’s the short circuiting or-statement. You’d have the same issues with debugging “if f() or g():...”

So are you arguing that the language should not have short-circuit or-statements?

That just seems like you are sacrificing tons of usability only to slightly improve on the expectations of those who are just starting python, like the first 1-2weeks of trying to learn it.

Agreed. List comprehensions are where I see them being the most useful and where, in the past, I wished the functionality had existed.

It's explicit with the new operator. The latter is true however.

I agree that it's a violation of the “one and only one” maxim, but that maxim is a bit hard to take as an absolute. I think the problem is that there are already a lot of ways to write things in Python, the biggest example that comes to mind is list comprehensions.

    outputs = [f(x) for x in inputs]

Versus:

    outputs = []
    for x in inputs:
        outputs.append(f(x))

The assignment expression lets you:

    outputs = [y for x in inputs
               if (y := f(x)) is not None]

I know that more complicated list comprehensions in Python are a bit of a sore point for some people, but I would say that they’re also inherently unpythonic, and I like them.

> I literally cannot read C code that does this,

Hogwash. You choose to not.

because it's too easy to typo:

`if foo == true:`

as

`if foo = true:`

which results in horrible subtle bugs

To reduce the chance of creating an assignment expression when you intended a simple comparison. Yes, there's already a different operator for equality, but it's easy to mistake = for ==. Forcing you to use := makes it a deliberate act, and makes your intention clear to the reader.

I think “Pythonic” is up there as one of my least-favorite terms of all time. I think, 99% of the time, when people say “Pythonic” they should really just be quoting one of the lines from PEP 20.

Yes, sometimes, writing a comprehension, I was dearly missing the `let` / `where`, as seen in e.g. Haskell, or lisps.

Omg really? Sweet!

What about functions, and functions of functions, etc? Can I specify that the argument to function f should be some other function g which should receive a list of ints and return a dict of functions with keys that are ints and values that are functions from int to int?

Just tried it. What's the point of type signatures if the compiler won't hold you to the promises you've made? This is in Python 3.6.4:

  >>> def f (x:int) -> int: return x+1
  ...
  >>> def g (x:str) -> str: return f(x)
  ...
  >>> g(1)
  2

I expected a complaint after the second definition: I specified that g takes and returns a string, and then defined it to take and return an int. Not only did Python not catch the error at compile time (defining g), it didn't even catch it at runtime (calling g).

I use Haskell outside of work, and absolutely love it. (And in its case, too, I'm holding my breath for dependent types, which I believe are expected around summer of 2020.)