On Sun, Apr 18, 2021 at 10:12 AM Larry Hastings <la...@hastings.org> wrote:
> 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
--
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/YDGLH25Z3MAXGGK2AJ44CINFPE6A2HIL/
Code of Conduct: http://python.org/psf/codeofconduct/
