On Sun, Jan 09, 2022 at 02:20:45AM +0100, jack.jan...@cwi.nl 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 -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/N42DDG3MKIVBSWHMONSBJIVMVK5H2COA/
Code of Conduct: http://python.org/psf/codeofconduct/
