Barry:
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. 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... Stéfane:
Using the same syntax may have some benefits for language implementors (e.g. less complex grammar to implement), but I don’t really see these benefits for language users.
As an example, and I don’t know if this has been discussed before, I think a pretty neat syntax construct for optional argument would be (like, for instance, in Kotlin):
def f(x: int? = None): ...
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. Your example here works fine for Optional, and looks pretty understandable if you know C# (or apparently Kotlin), but it doesn’t solve all the other problems with readability. And I think you’ll quickly run out of constructs once you try to fix more problems if you don’t want to clash with existing Python syntax… -- Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman