Haven't seen a reply to this yet, so I'll start the bidding at 2¢.
Generally, I like the idea of using Annotated in this fashion. I'm currently using it for expressing validation rules and hints about how parameters are handled in HTTP requests. Handy!
If = field(...) weren't already established, I'd say it should be as an annotated value instead of an assignment. Since = field(...) pattern is well established, I'm not so sure what the value would be of changing this in dataclass now.
On Sat, 2021-04-03 at 20:57 +0000, firstname.lastname@example.org wrote:
typing.Annotated could be used to build dataclasses. Using Annotated will allow libraries to add functionality to a dataclass without having to change dataclass creation or behavior. The example below shows how a dataclass could be implemented. It continues the example of struct2 shown in pep593. From a dataclass point of view, the Sample and AnnotatedSample would be equivalent.
c: int = field(default=5)
d: int = 10
e: int = field(default=10)
a: Annotated[int, ctype("I")]
c: Annotated[int, field(default=5), ctype("I")]
d: Annotated[int, ctype("h")] = 10
e: Annotated[int, ctype("h")] = field(default=10)
out_bytes = struct2.pack(AnnotatedSample())
When parsing the Annotated parameters, the dataclass decorator will only look at the type parameter and ```field``` parameter if present. If not Annotated, it falls back to existing behavior.
Let me know what you think.