Thanks to Barry and the SC for giving us this update. > In the interest of full transparency, we want to let the Python community know that the Steering Council continues to discuss PEP 563 (Postponed Evaluation of Annotations) and PEP 649 (Deferred Evaluation Of Annotations Using Descriptors).
<snip> I want to draw attention to this point: > all the use cases and requirements across the static and dynamic typing constituents. TL;DR: 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"), but if the SC is reconsidering PEP 563, then it would be nice to be clear about whether non-typing uses of annotations are indeed deprecated. If not, then the challenge is to come up with a way forward that not only supports both static and dynamic typing, but also other potentially arbitrary use cases. And now onto more detail ... 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. Of course, there are other ways to write that code, but I'm pretty sure it would require a complete change to the API. I'm not entirely sure if PEP 646 would work for my use case -- likely it would, at least with modest modifications, rather than a new API. I have no idea how many other similar use cases are out in the wild, but we know that the Pydantic project has concerns. To be fair -- I wrote all my code after PEP 563 was accepted. And I only just now read it carefully, and found that it says: "With this in mind, uses for annotations incompatible with the aforementioned PEPs should be considered deprecated." If that's the case, then that's the case, and I'll deal, but it is disappointing. But I suspect I'm not alone in not really noticing that statement, so I think it's worth it for the SC to explicitly reiterate at this point that all non-typing uses of annotations are depreciated, if indeed, that is still the intent. Also, that statement is not entirely clear. In fact, I think my use case IS compatible with the "aforementioned PEPs", it's just not compatible with PEP 653 itself. It all depends on what is meant by "compatible". I would like to provide a bit of perspective on this. I was criticised on this list a while back for, essentially, not paying attention and then complaining later. After all, PEP 563 was accepted over four years ago. Fair enough. But the fact is that I, among others, have been a bit uncomfortable about the focus on typing in Python for years. But when issues are raised, we have been repeatedly told that typing is, and always will remain, optional. In short, it was made clear that anyone not interested in typing could safely ignore the discussions about it. And thus, a number of PEPs came and went, and those among us that did not choose to involve ourselves in the conversation did not pay attention to the details. And thus we didn't notice that buried in what seemed like a typing PEP, was, in fact, a depreciation of any non-typing uses of an existing Python feature. (also to be fair, the title of the PEP is "Postponed Evaluation of Annotations" -- so should have caught the attention of anyone interested in annotations for any use. In my personal case, I didn't notice it at the time, as I wasn't using annotations for anything at all until fairly recently. In fact, it was the introduction of dataclasses, which I think are the first use of annotations in the standard library, that drew my attention. dataclasses, as I'm sure you all know, use the presence of an annotation on a class attribute to define a field. This is a pretty nifty use of annotations as an API for defining the fields. I liked that, and decided to use it. dataclasses create a Field object, which has an attribute called "type", that gets populated with the annotation's value. PEP 563 would very much change what gets put in the "type" attribute of a Field. Eric V. Smith has indicated that he never intended that to actually be a type, but rather was intended to be whatever the annotation was, so that PEP 563 wouldn't change anything. I'm happy to take his word for it (and PEP 567 says that the actual type is not used or modified by dataclasses), but as users, all we have to go on is the documentation and the choice of names, which very much gave the impression that a Field.type would be a type -- at least if a type was set in the annotation. I also notice that PEP 567 (dataclasses) and PEP 563 were both developed and approved at about the same time. So I suspect the impact of PEP 563 was not considered when designing or documenting dataclasses. However, PEP 567 does make a number of references to typing, and was clearly written with the idea in mind that the annotations would, in fact, be used for type analysis. But again, no mention of PEP 563, or what might be in the field.type attribute -- one might wonder why it was there at all if it was not intended to be used. We need help in defining those requirements clearly, in uncovering the use > cases we’re not aware of, and most importantly, being an interface to > typing enthusiasts Again -- is it only "typing enthusiasts" that you want to engage? Or "users of annotations"? -- maybe it is, but it would be nice if that was a clear statement from the SC. - 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/MAPFC2O5YRCH6LFGBIX4YEFG4G5X7VSH/ Code of Conduct: http://python.org/psf/codeofconduct/
