First: At this point, I am not advocating anything in particular. I am just asking that the SC makes a clear statement about the intention at this point.
>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. (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? On Thu, Nov 25, 2021 at 7:15 AM Stephen J. Turnbull < stephenjturnb...@gmail.com> wrote: > The typing-suspicious crowd has a valid complaint about PEPs 563 and > 649, but it's not that they weren't warned. > Well, "typing-suspicious" is part of it, but the real problem is folks that might be using annotations for non-typing purposes. As for warning: yes and no -- what's new here is that as far as I know, this is the first time since the py3 transition that a __future__ import would be made standard behavior. And you'd have to be paying a lot of attention to know that was going to happen. And I suspect that only folks involved in the development of typing tools were paying that much attention. In the case of the py3 transition -- it was very well known and documented that lots of things would be changing, and we had a very long transition period. But the challenge with this is that there is no way to raise a depreciation warning for not using a __future__ import. So while we all should have been testing our code with: from __future__ import annotations For the last few versions, I doubt that very many people not developing typing tools were doing that. > Annotations can be, and are, used for other things than "typing". I > > just noticed that PEP 563 apparently deprecated those other uses > > (well, sort of: "uses for annotations incompatible with the > > aforementioned PEPs should be considered deprecated") > > Not a PEP proponent (or even a typing user), but I thought this had > been made clear long ago. My understanding is that optional, > incremental type hints are and have always been considered the primary > use case for annotations by the BDFL and AFAICT the SC following the > BDFL. well no -- not "always" -- look at PEP 3107, when annotations were first introduced: "By itself, Python does not attach any particular meaning or significance to annotations." and it goes on to give non-typing examples. Since then, the shift from "nothing more than a way of associating arbitrary Python expressions with various parts of a function at compile-time" to a system for defining types has been gradual, with a number of PEPs, and, as far as i can tell, PEP 563 is the first time that a change was proposed that would affect other uses for annotations. Anyway, that is water under the bridge. But the reason I bring it up is because of all the many thousands of Python users, I pay probably more attention to changes than most -- I have followed Python-ideas and Python-dev for years. So I'm guessing that there are other folks out there that will be surprised if and when the behavior of annotations changes. > If compatibility with typing is an issue, then the burden of > implementing that is on the other application. That does indeed seem to be the current intent. And I'm happy to deal with that -- I just want it to be clear that I (and others) have to wait and see how it shakes out, and then figure out what to do, or if I should contribute to the conversation now. If non-typing use cases of annotations are still considered important, then we should encourage folks like me to be part of the conversation. > > I'm not entirely sure if PEP 649 would work for my use case -- > > likely it would, at least with modest modifications, rather than a > > new API. > > If PEP 649 works for you, I expect you could work with PEP 563 by > moving Larry's data descriptor concept out of the compiler and into > your library code. > That would indeed require maybe not a change to the API, but certainly some complex code. But yeah, probably doable one way or another. > > But I suspect I'm not alone in not really noticing that statement, > > I am > surprised that a lot of folks haven't noticed that this comes up > occasionally and the answer every time is "we're not going to go out > of our way to break other use cases, but typing *is* the primary use > case and will take precedence if the question comes up". > I think the "breaking other use cases" has been subtle to those not paying attention to typing. > > But the fact is that I, among others, have been a bit uncomfortable > > about the focus on typing in Python for years. > > You mean y'all are uncomfortable with the popularity of typing. You > wouldn't care if it wasn't used outside of hugely complex proprietary > codebases you'll never see. > 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. But that's getting pretty OT here. > Anything that helps > *other people* to write better code, I can get behind. My code, I'm > going to write as incompetently as ever.[1] ;-) > me too -- actually, not quite. I write a lot of "scripts" that I will continue to keep simple, and I also develop complex systems -- and those require more care. > > But when issues are raised, we have been repeatedly told that > > typing is, and always will remain, optional. > > This has always been in the context of *your* source code. Sure -- my point with that is that if I don't want to use typing in my code, then I didn't have to pay attention to the development of the typing systems. But my point here is that what changed with PEP 563 is that while typing is still optional, this is the first time that the language itself may be changed to accommodate typing -- so it can no longer be completely ignored. But dunders are the property of the language (or sometimes the > implementation), and they always have been. If you use them in a way > that's not documented to work, you're at risk even if it happens to > work now. PEP 3107 didn't document that anything would work. ;-) > no, but it did document that annotations were "arbitrary Python expressions" -- that is changed in PEP 563 -- intentionally, but it is changing something about the language that was documented. -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/ML3OSGC2DPLLAEDOXGT2XK2S3UJ5AY23/ Code of Conduct: http://python.org/psf/codeofconduct/
