Since you linked to the discussion Why does Python assignment not return a value, I'll assume you understand that part.
What you're missing is a fundamental assumption that wasn't stated explicitly in the answers to that question, and which is often not stated explicitly:
Python does not have any way to embed statements into expressions.
If this were not true, there would be no point in having the statement-expression divide in the first place. That's why scripting languages that can embed statements into expressions, like JavaScript and Ruby (and, to a lesser extent, traditional C-family languages like Java and C++*), generally try to make everything possible into an expression, with some kind of useful value. There's no good reason not to do so in those languages.
Because it is true, Python gets a number of benefits from the statement-expression divide that make it easier to read, and easier to parse. For example, indentation-based block structure is much more complicated (both for the interpreter, and for the reader) if you can indirectly start a new statement in the middle of another one.
There's another property that is discussed, but which relies on some conventions in the stdlib and third-party code and in your own code. As long as nobody writes functions that both mutate state and return a useful value, you know that each statement changes exactly one thing—whether it's an assignment statement, or an expression statement with a mutating function call.** Yes, you can subvert it (e.g., you can toss a n.sort()
into a list comprehension if you really want to), but unless you go out of your way to do so, this feature dramatically improves the readability of state-mutating imperative code.
Once you realize that you can never embed statements into expressions, your question becomes trivial. Since b=10
is a statement, it cannot be embedded in an expression.
* Or, really, most Algol-family languages, of which the C family are just one branch. In fact, Algol 68 found a simple way to turn everything into an expression—make a statement a kind of expression. Most other Algol derivates didn't pick that up, and over the years have rebuilt it by turning more and more kinds of statements into expressions…
** Well, obviously a, b = 2, 3
or a = b = 2
change two things—but it's still obvious what those two things are, and where to find them in the statement.