I hope my understanding of where the SC’s debate about this currently sits isn’t a misrepresentation, but since I sent the email on behalf of the SC, let me try to clarify what I was trying to say.
Aside: A little insight into how the SC works. For communications like this, after whatever debate we have in our live weekly meetings (and sometimes off-line discussions in Slack and email), one of us volunteers to write a draft of the email. We then all comment and wordsmith until we’re in unanimous agreement that it’s ready to go out. Then usually the person who wrote it will send the email. We all have slightly different styles, but I usually sign it with my name “on behalf of the Steering Council”. That’s my way of saying that the communication comes from all of us and represents the SC’s opinion, but it generally has the written style of the original drafter. > On Nov 25, 2021, at 13:41, Christopher Barker <python...@gmail.com> wrote: > From Barry's email: > """ > This is also a call to you, the folks who both care deeply about typing in > Python, and have a solid understanding of the subject matter (or willingness > to learn) to help us! There are use cases we don’t know about, and unclear > requirements from both the static and dynamic typing users. > """ > I don't care deeply about typing, and I'm not a static or dynamic typing > user. So this implies that a decision has been made that annotations are for > typing, and typing only. Practically speaking, I think that’s current reality: annotations are for typing, be they static type checking or dynamic runtime uses. I was inelegantly saying that even with that narrower interpretation of annotations, there are use cases, interactions, side-effects, semantics, and implications that we do not fully understand. PEP 563 and 649 have visible effects that even within that domain can have important side effects. For example, PEP 563’s loss of local scope, which even “de-stringify-ing” can’t recover. This is what we need help with. > (not that you're not allowed to use for anything else, of course you are, but > that other uses won;t be taken into account when designing the new interface) > > But I have never seen that clearly stated anywhere. The closest is from PEP > 563, where it says: > > """ > With this in mind, uses for annotations incompatible with the aforementioned > PEPs should be considered deprecated. > """ > > Which pretty much makes the point, but it's a bit subtle -- what does > "incompatible' mean? You make a good point. I agree that while all the signs are there for “annotations are for typing”, this has never been explicitly or sufficiently codified, and I’ve been proposing that Someone write a PEP that makes this an official pronouncement. That someone may very well be a person on the SC, but given the timing of elections, it’s likely to fall to the next SC, if they still agree with that position! :-D My recollection of the history of annotations falls somewhere between Greg’s and Guido’s. Annotations as a feature were inspired by the typing use case (with no decision at the time whether those were to be static or runtime checks), but at the same time allowing for experimentation for other use cases. Over time, annotations-for-typing clearly won the mindset and became the predominant use case. Personally, I was strongly against type annotations because of my experience in other languages, but over time I was also won over. From library documentation, to complex code bases, to the transient nature of contributors, type annotations are pretty compelling, and most (but not all) of my worries really didn’t come to fruition. We can lament the non-typing use of annotations, but I think that horse is out of the barn and I don’t know how you would resolve conflicts of use for typing and non-typing annotations. It’s been a slow boil, with no definitive pronouncement, and that needs to be fixed, but I think it's just acknowledging reality. That’s my personal opinion. > well, yes. The issue is that, intended or not, typing is making it's way into > Python culture. As an instructor of beginning python users, I am unsure at > this point when to introduce type annotations. > > What is their role? Up to today, I have treated them as an advanced feature, > useful for "complex codebases". But there are any number of examples > springing up on the internet, to the point where many students now think they > are "best practice", if not actually required. This is an important observation. As much as I’m in the "type annotations are good” crowd now, I still think they should always be optional. Python’s use is so broad these days, I for one don’t want to have to add annotations to every bit of Python I write. -Barry
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ 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/COUJ2QW42OTUUZLW6VJTZBOP364F4CR2/ Code of Conduct: http://python.org/psf/codeofconduct/
