No, I cannot, and that is the exact problem. You think that only one of them corresponds to a program that “makes sense” to write, but computers cannot read your mind and do not have any concept of “common sense”. If they did, they would write the program for you - you could just ask ChatGPT, or some very simple system built around ChatGPT , and would never run into any problems.
(And then our robot overlords would overtake us…)
but in case of function declaration computer able to recognize it
I have no strong opinion on whether or not it is a good precedent. The fact that the modern C and C++ no longer supports the syntax may suggest that it isn’t, while the fact the JavaScript and R adopt a simple arrow syntax for function definitions may suggest that it is. As long as it is unambiguous I can get used to it either way.
That was my point.
But they have a specific piece of syntax for it. Yes, that piece of syntax is part way into the expression rather than at the beginning, but that arrow always means “hey this thing here’s a function”.
And that’s precisely the issue. It needs to be unambiguous. That’s why there usually needs to be either a word or a symbol to represent what you’re trying to say.
Technically speaking what the OP proposes is unambiguous if it only applies to function definitions, but you’re right about JavaScript and R’s arrow syntax in that their arrows show up right after the function names so those who read the code can immediately understand that they are about to read a function definition, while with what the OP proposes here one would have no idea whether this is a function call or a function definition until many lines later:
big_function(
a,
b,
c,
d,
e,
...
):
pass
And equally technically, it is NOT unambiguous if it also applies to class definitions, as the OP proposed.
For sure, bu
no doubts, but in case we consider only function decalration it can work.
it’s like semicolon in JavaScript, you can use it or not and there is no error.
If I care about my code readability I will use def, if I am not, I won’t
Except with return statements, where it becomes an extremely annoying quirk. Ambiguity is a flaw, not a goal, and not something to use as inspiration.
So what you’re saying is that your proposal harms readability?
First reply for my post said
Whether they are needed technically isn’t relevant. They are needed to make Python code readable for humans .
I think the reason you get pushback here is because most devs don’t want to potentially reduce readability to save 4 keystrokes. Code golf can be fun but we don’t need to make Python a code golf language.
the question is how readablility is reduced.
Also is a good question why we need to use a colon when our body goes on the next line? For sure, in case function body on the same line it makes sense, but why do we need it when it is not?
Currently, many things in Python follow the pattern
keyword <other stuff>:
block
So what we as Python developers tend to look for are the keywords. They are conveniently placed at the beginning of a line and very clearly signal intent. The colon however only tells us that a block of code follows. So if tou remove the def keyword, developers would have to read a lot more of the code before knowing if it’s a function def or a function call. That’s not what I or, presumably, most Python devs want. But, readability is often i the eye of the beholder so you might think differently.
Just a quick note: you have a very combatative tone in your posts, and I think you’d get a lot more constructive feedback if you make your posts less aggressive 
What does this mean in your scheme?
match (x):
case (y):
...
I’m not sure if it would be technically possible to simply remove def and class and not run into parsing ambiguities. Assuming (just for the sake of argument) that this is possible, then it is true that removing those keywords reduces some redundancy, and doing this optionally would not break existing code. But this would come at a very high cost. The language would no longer explicitly mirror two core, high-level, very different concepts (functions and classes). It would (greatly) decrease code readability and increase ambiguity for humans. It would also increase the complexity of the underlying Python parser. All in all, this would also greatly increase the risk of introducing bugs and make code maintainability much harder. Having more options is not always desirable…
To quote the Zen:
There should be one-- and preferably only one --obvious way to do it.
There would need to be some very strong motivation to have two different syntaxes for doing the same thing. I don’t think saving a few keystrokes rises to that level.
Answer here is clearly that this is not a good idea. Closing to prevent further permutations of explaining why.