On Fri, Jan 7, 2022 at 4:04 PM <jack.jansen@cwi.nl> wrote:
I posted this suggestion earlier in the callable type syntax discussion, at which point it was completely ignored.

Maybe not. I made a similar suggestion early in the thread, and Brett Cannon said that the SC had rejected that approach.

But I’m not sure when that was— is it time to revisit the idea? 

Note that if PEP 563 is ultimately accepted, then Annotations would be strings, and type checkers could use any language they wanted. 

In fact, right now annotations can
Optionally be strings anyway. 

I don’t think that would be good for the community to have multiple sys to do it,  but it might be a way to experiment.


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.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

Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython