On 4/17/2021 11:43 PM, Larry Hastings wrote:
The heart of the debate between PEPs 563 and 649 is the question: what should an annotation be? Should it be a string or a Python value? It seems people who are pro-PEP 563 want it to be a string, and people who
are pro-PEP 649 want it to be a value.
Actually, let me amend that slightly. Most people who are pro-PEP 563 don't actually care that annotations are strings, per se. What they want are specific runtime behaviors, and they get those behaviors when PEP 563 turns their annotations into strings.
I have an idea--a rough proposal--on how we can mix together aspects of
PEP 563 and PEP 649. I think it satisfies everyone's use cases for both PEPs. The behavior it gets us:
* annotations can be stored as strings * annotations stored as strings can be examined as strings * annotations can be examined as values
I agree that somehow satisfying more people rather than fewer is a good goal.
The idea:
We add a new type of compile-time flag, akin to a "from __future__" import, but not from the future. Let's not call it "from __present__", for now how about "from __behavior__".
I have wondered whether the current split over annotations constitutes sufficient 'necessity' to introduce a new entity. The proposal for permanent Python dialects, as opposed to temporary dialects, is not new, as indicated by your reference to '__present__'. It has so far been rejected. Some people, upon having their syntax proposal rejected, have proposed that it be made an option. I believe that others, not liking a accepted change, have proposed that the old way be kept as an option, or that the new way be optional. So I think that we should first look at other ways to meet the goal, as proposed in other responses. -- Terry Jan Reedy