On Sun, Jan 09, 2022 at 02:20:45AM +0100, [email protected] wrote: > 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 disagree. > 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: mydict[key] 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: Range[10] 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. -- Steve _______________________________________________ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/N42DDG3MKIVBSWHMONSBJIVMVK5H2COA/ Code of Conduct: http://python.org/psf/codeofconduct/