I think that's reasonable. But I don't think Python is the language
for that. There are too much existing contrasts, such as loop vs.
comprehension and conditional statement vs. ternary expression. Guido
deliberately chose to vary those expression syntaxes from their
statement equivalents. I don't think there's any ambiguity if you say
that wrapping a compound statement in parentheses creates an
expression with restricted syntax (namely, the statements the syntax
controls become expressions):

   (if condition_1: expression_1
    elif condition_2: expression_2
    else: expression_else)

   [for element in iterable: if condition: expression(element)]

But Guido (and I think everybody else) thought "Noooo! not *that*!”

??????????
`Deferred evaluation`, if was to gain traction in a similar manner
as e.g. `annotations` are now experiencing, would cover all of the
cases I was looking at & more.

As Chris was saying earlier, it's at minimum going to take some genius
creativity to "cover all and more", because a closer look at what
people mean by "deferred" shows that in different cases it is
semantically different. In particular, there are a number of choices
that Chris made in PEP 671 that aren't compatible with several of the
proposals for Deferred objectss, while Deferreds can't give some of
the benefits of the PEP.

I have read both PEP671 and https://github.com/DavidMertz/peps/blob/master/pep-9999.rst, but can’t see what benefits does PEP provide, that def-eval can not. I see that they are not the same in implementation even orthogonal, but it seems that PEP671, maybe not as elegantly, but can achieve the same result.

I didn't like that PEP then; I was in the camp of "let's get genuine
Deferreds, and use them to cover some of the use cases for PEP 671."
I don't actively want the PEP now. def-time evaluation of defaults
doesn't catch me and I haven't had trouble teaching it. The
"if arg is None: arg = Mutable()" idiom is rare enough that I prefer
it to adding syntax to the already complex function prototype.

That idiom is only 1 example. See my e-mail with examples of how def-eval relates to several PEPs and requests that came up recently in this group. It would improve things in many areas. E.g. infix operators might become an actually useful thing instead of being just a cool thing to take a look at. IMO, infix pattern is too cumbersome to be used as actual operator, but would be perfect for defining binary and maybe ternary expressions.

If it’s usage would be as in “def-eval rst", it would potentially bring about a new paradigm to the way I do things. Especially if it was well optimised and had a concise syntax.

# something similar to
`expr`
# or
?(expr)

But if you think it might be a good idea, I encourage you to take a
close look. For some use cases it's definitely an improvement, and at
least I won't vocally oppose the PEP now -- haven't seen any progress
on "true Deferreds". Perhaps others' opposition has softened, too.
Adding another proponent is another way to help get it going again.

I am not sure if I would be the right person for this, but if you know any good places (discussions or attempts) to look at apart from that “def-eval rst”, I would take a look. So far I am only excited about it from user’s perspective…