On 4/18/21 9:14 AM, Richard Levasseur
wrote:
Alternatively: what if the "trigger" to resolve the
expression to an object was moved from a module-level
setting to the specific expression? e.g.
I genuinely don't understand what you're proposing. Could you
elaborate?
I can't speak for Richard, but Interpreted this as:
Have a way to specify, when you write the annotation, whether you want it evaluated or kept as a string.
in my previous post, I added the idea of the semantics (am I using that work right?) as meaning "run-time" vs "non-run time (type check time)" -- that is, do you want this to be a valid value that can be used at run time? But it could only mean "stringify or not".
I will note however that your example adds a lot of instances of
quoting and curly braces and the letter 'f'. Part of the reason
that PEP 563 exists is that users of type hints didn't like
quoting them all the time.
I think Richard suggested the f-string because it's currently legal syntax. And you'd get syntax checking for anything in the brackets.
But we could come up with a nicer notation, maybe a double colon ?
class A:
x: int # you can stringify this one
y:: int # please don't stringify this one
maybe that's too subtle, but in this cse, maybe subtle is good -- to the reader of the code they mean pretty much the same thing. To the writer, they are quite different, but in a very testable way.
And this would preserve:
PEP 563 meant that syntax errors would be caught at compile-time.
It would also open the door to extending the syntax for typing as is also being discussed.
Granted, adding yet more syntax to Python nis a big deal, but maybe not as big a deal as adding another dunder, or removing functionality.
Also, could a __past__ import or some such be introduced to make the new syntax legal in older supported versions of Python?
As I think about this, I like this idea more and more. There are three groups of folks using annotations:
1) The Static Type Checking folks: This is a large and growing and important use case, and they want PEP 563, or something like it.
2) The "annotations ARE type objects" folks --this is a much smaller group, at least primarily -- a much larger group is using that functionality perhaps without realizing it, via Pydantic and the like, but the folks actually writing that code are more select.
3) I think BY FAR the largest group: Folks using type annotations primarily as documentation. (evidenced by a recent paper that whent through PyPi and found a LOT of code that used type annotations that apparently was not using a Type checker)
So it seems a good goal would be:
Have nothing change for group 3 -- the largest and probably paying the least attention to all this.
Have things work well for group 1 -- Type Checking seems to be of growing importance.
Require only a small manageable update for group 2 -- important, but a smaller group of folks that would actually have to change code.
(hmm.. maybe not -- not many people write libraries like Pydantic, but all the users of those libraries would need to update their type annotations :-( )
-CHB
--