This is great Patrick, thanks. My use case is similar to Patrick's, except it builds on dataclasses directly:
It's part of a larger system, but I've just pulled it out into its own poorly documented and poorly tested package: https://github.com/PythonCHB/flexi (I think it's generally useful, so may one day make a proper package out of it) Anyway, the principle is this: The goal is to have a flexible data model that enforces the structure, but not necessarily the validity of values, or even types. This is useful because we need to store / edit / import complex hierarchy of data, and we very much don't want to have all of it to have to be valid in order to even store it. An example is a dataset we recently imported (from spreadsheets--arrgghh), where in a thousand records, they had put "too viscous to measure" instead of a value for interfacial tension. That, of course, would be helpful to a person reading the spreadsheet, but would have been a pain if we had enforced that that field had to be a float > 0. Instead, it imported fine, and then our validation code flagged the issue to be fixed later. And all the rest of the data could be used in the meantime. Anyway, that was a digression (but explains why we don't use Pydantic). Functionally, we need the "nodes" in the data model to be able to convert themselves to/from JSON compatible Python, and validate themselves, etc. This is done by using the actual type object, as stored in dataclasses.Field.type This has worked nicely for us, and dataclasses saved us a lot of boilerplate code. if we do from future import Annotations then the system breaks, as we have a string instead of the actual type that is needed. Solutions: I *think* PEP 649 would work fine for us, as the annotation would get evaluated when it was added to the field object. But inspect.get_annotations isn't really helpful for this use, as the Field.type attributes aren't annotations anymore. So we would have to eval() the strings ourselves, and I think it would be unclear what namespaces to use for that. If dataclasses were to use inspect.get_annotations(cls, eval_str=rue) in order to extract the types to put into the Field objects, then I think all would be good for us. And as I understand it, dataclasses itself doesn't do anything with that attribute anyway. If that's not decided to be a good thing for dataclasses, then I think we'd have to re-implement a lot ourselves, though it could probably be hacked in - I haven't tried that yet. BTW, I don't think we've heard from the attrs (and especially cattrs) folks in this thread. A search of the repo issues indicates that there has been some discussion of PEP 563's impact, but it's not totally clear to me if it's been resolved. -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/ZYWLGMP5UO7NTABVJJOHN7ZSS4KUM6UG/ Code of Conduct: http://python.org/psf/codeofconduct/
