Why does it need to beattrs.fields(Parent).a.evolve(default=200).to_field() instead of maybeattrs.fields(Parent).a.to_field(default=200)? We'll need to add Mypy support to this before it can be used for real, and we should look at making that as easy as possible.

If the goal is to reduce function chains, then how about the keywordreuse()? That might be more descriptive in this context thanto_field():

classA:x=attrs.fields(Example).x.reuse()y=attrs.fields(Example).y.reuse(default="whatever")_z=attrs.fields(OtherExample).a.reuse(alias="z")

I like it!

What exactly should I annotate for mypy? I notice that neither the return result ofattr.fields() nor_CountingAttr itself have annotations already:

Should I just try to annotate everything this new feature touches? The contribution guidelines are a bit sparse in this regard.

Soy = attrs.fields(Example).y.reuse(default="whatever") is cool indeed – I'm just not sure if that will ever be possible to get into typing at all??

I'm kinda OK with saying that you have to redefine your types, otherwise it gets hairy with ordering anyways (or some magic helper type, e.g.,y: Annotated[Inherit] = attrs.fields(Example).y.reuse(default="whatever")).

But how could any of this be made type-safe?y: Annotated[Inherit(attrs.fields(Example).y, default="whatever")] would be probably even cooler since it circumvents the ordering problems, but I guess we should think ahead here? Does maybe Pydantic have something similar so we could join PEP forces or something?

We could contribute work to the mypy plugin so it would work 😇

I'm kinda OK with saying that you have to redefine your types, otherwise it gets hairy with ordering anyways (or some magic helper type, e.g., y: Annotated[Inherit] = attrs.fields(Example).y.reuse(default="whatever")).

This would make sense. The only reason it is omitted in this particular implementation is because the type is already inherited from thereuse() call and (re)including a type annotation would be akin to defining it twice, which attrs complains about. This can simply be rewritten to not inherit the type, and to default toAny if no type annotation is provided.

y: Annotated[Inherit(attrs.fields(Example).y, default="whatever")] would be probably even cooler since it circumvents the ordering problems

This is not a bad idea. If I understand you correctly, does that make the proposed syntax:

@attrs.defineclassA:x:int=10y:str=attrs.field(default="blah")@attrs.defineclassB:z:dict= {"test":"result"}@attrs.defineclassChild(B,A):x:Annotated[Inherited(attrs.fields(A).x,default=20)]# Preserve parent orderingy:str=attrs.fields(A).y.reuse()# Add to end after inheritedz:Annotated[Inherited(attrs.fields(B).z,factory=dict)]# Preserve parent orderingassert"Child(x=20, z={}, y='blah')"==repr(Child())

It seems the question of what order to put inherited fields in is not trivial. I suppose you could argue that if you need absolute control of field order, then you should create an entirely composite class usingreuse() and ignore inheritance entirely, which violates DRY a little but keeps things obvious.

We could contribute work to the mypy plugin so it would work 😇

I'll look into this. I assume you're referring tothis?