This is actually a topic the 2021 SC discussed at length and at the time we decided that the typing language should follow the execution language. It was buried in the call type syntax thread so it’s was probably easy to miss:
https://mail.python.org/archives/list/python-dev@python.org/message/4TY3MVJQOLKSTMCJRTGAZEOSIIMAWQ45/ Of course, this decision can be revisited by the 2022 SC. -Barry > On Jan 7, 2022, at 15:59, jack.jan...@cwi.nl wrote: > > I posted this suggestion earlier in the callable type syntax discussion, at > which point it was completely ignored. Possibly because it’s a really stupid > idea, but let me post it again on the off chance that it isn’t a stupid idea > but was overlooked. > >> If I can make a wild suggestion: why not create a little language for type >> specifications? >> >> If you look at other programming languages you’ll see that the “type >> definition sub-language” is often completely different from the “execution >> sub-language”, with only some symbols in common and used in vaguely related >> ways. `bool (*myfuncptr)(int, float*)` uses a completely different set of >> syntactic rules than `rv = (*myfunptr)(*myintptr, &myfloat)`. So with some >> grains of salt you could say that C is comprised of a declarative typing >> sublanguage and an imperative execution sublanguage. > > And an even better example is Pascal, which uses a set of syntactic > constructs for typing that are completely different from the execution > statement syntax: `var a : array[1..10] of real` looks very different from > `a[1]`, where C `float a[10]` looks pretty similar to `a[10]`. > > The next bit of my original email is another wild idea, the previous bit > doesn’t depend on it really. I can imagine completely different ways of doing > a typing sublanguage: > >> Python typing uses basically a subset of the execution expression syntax as >> its declarative typing language. >> >> What if we created a little language that is clearly flagged, for example as >> t”….” or t’….’? Then we could simply define the typestring language to be >> readable, so you could indeed say t”(int, str) -> bool”. And we could even >> allow escapes (similar to f-strings) so that the previous expression could >> also be specified, if you really wanted to, as t”{typing.Callable[[int, >> str], bool}”. > > -- > Jack Jansen, <jack.jan...@cwi.nl>, http://www.cwi.nl/~jack > If I can't dance I don't want to be part of your revolution -- Emma Goldman > > > > _______________________________________________ > 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/26JB6YIPWXUSTQSXTVSZMUS6FM4RZBJA/ > Code of Conduct: http://python.org/psf/codeofconduct/
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ 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/FRLJ6HS3LMF3LYG5WAF5RBYQIWEQASZX/ Code of Conduct: http://python.org/psf/codeofconduct/
