On Fri, Jan 7, 2022 at 4:04 PM <jack.jan...@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.
-CHB
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/
>
--
Christopher Barker, PhD (Chris)
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython
_______________________________________________
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/WW6YHV45OUEAIJCYWZ7TLAEGUO75QEOW/
Code of Conduct: http://python.org/psf/codeofconduct/
