On Sun, Jan 09, 2022 at 02:20:45AM +0100, firstname.lastname@example.org wrote:
The advantage to users of keeping the languages the same is that readers of your code don’t have to learn two disparate syntaxes to make sense of what they’re reading. One of Python’s enduring strengths has been its readability.
Agreed. But if the little language is (a) clearly flagged and (b) has a different domain I think this is much less of a problem.
I don’t think f-strings are seen as a problem, far from it, because they’re clearly flagged.
On the contrary, f-strings are not really a second language. f-strings involve *ordinary Python expressions* plus a set of formatting codes which are mostly similar or identical to those used by the format method and string interpolation with the `%` operator.
That’s why I suggested t-strings. And while from a Python parser point-of-view the grammar of current type expressions are the same as the grammar of other Python code I think that for human readers this is not the case: there’s a lot of square brackets but nothing is being indexed, to name one major readability issue...
Nothing is being *indexed* here either:
I don't think that Mathematica code is harder to read because it uses square brackets for function calls instead of round brackets. I challenge you to say that you cannot read these:
FindShortestPath[graph, start_vertex, target_vertext]
Even when Mathematica uses syntax that is unfamiliar, I expect that you would be able to guess what this does:
StringReplace["abbaabbaa", "ab" -> "X"]
and if you can't, it's not because of the square brackets.
As I mentioned in a previous email, I can see a number of reasons why typing is hard, but the syntax (ordinary Python expressions) is not why it is hard.
We can, I think, improve elements of the typing DSL. `T|S` is, I think, an improvement over `Union[T, S]` for the same reason that `a|b` would be an improvement over `bitwise_and(a, b)` or `set_intersection(a, b)`.
Likewise, I think that we should accept PEP 677 (arrow notation as sugar for Callable).
But I wouldn't want to see type hints diverge into a completely different language from Python.
I introduced the t-strings specifically because I think it would be beneficial to have the little language a clearly flagged and have as little interaction with “normal” Python as possible.
And that is exactly why I think that it is not a good idea. Having type hints use regular Python syntax is not a design flaw to be fixed.