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*!”
Yes, I realise that there is no way back as different direction has already been taken. So I am not (and have not been) proposing any changes there, just trying to find ways to get to where I would like to with python.
?????????? `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 <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… DG