Executive summary: The typing-suspicious crowd has a valid complaint about PEPs 563 and 649, but it's not that they weren't warned.
Christopher Barker writes: > 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. If compatibility with typing is an issue, then the burden of implementing that is on the other application. Typing *might* do something to help, but it's not obligated to do so. > One example is a use case of mine -- I have built a hierarchical > object system, built on dataclasses, in which the annotation > absolutely has to be an actual type(class) object. PEP 563 will > very much break this use case. [...] > 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. You could also appeal to the "might do something" caveat above. Yury suggested providing both the immediately evaluated object (if there were no forward references, I guess) and the string representation, which would be backward compatible with your use case. The idea was rejected on the basis that it doesn't help with the primary use in typing, and doesn't remove the need for a __future__ import during the transition period. You could ask that that decision be revisited, since it would ensure that uses of __annotations__ like yours continue to work. > But I suspect I'm not alone in not really noticing that statement, I'm not surprised people haven't noticed 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 will grant that restricting the type of compiled annotations from typing.Any to "string serializing an object's AST" could reasonably be said to be "going out of your way to break other use cases". You have a valid beef here, although it's not obvious to me how it should be resolved. So I'm not saying that you don't have an interest in the future semantics of this dunder. I am +1 on Python providing relief for your use case. > 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. Thing is, reasoning about programs is What We Do as programmers, and efforts to make it easier to do that for complex programs, and to provide software to help with that task, are here to stay and they will be used in mixed company. Even in Python. (And that's why, as someone who doesn't use typing, I support typing. 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] ;-) > 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. For example, nobody ever claimed you could keep it out of anybody else's source code (although that's clearly what a lot of those "raising issues" want!) Still, features like stub files were provided so typists could work and play nicely with non-typists if they wanted to (and many typists want that, themselves). 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. ;-) Footnotes: [1] Barry, do not tell Abhilash I wrote that. _______________________________________________ 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/2O3JHKJ2CM7OFNGT664WXLN2DKU3YGIS/ Code of Conduct: http://python.org/psf/codeofconduct/
