I do know about Moose and it has been on my agenda to look for inspirations once I run out of own tasks…which weirdly hasn't happened yet. 🤪

Before changing APIs, you can access the field definitions while declaring fields. Which means that the following works:

@attr.s
class Two(One):
    myattrib = attr.ib(
        default=2,
        validator=attr.fields(One).myattrib.validator,
        converter=attr.fields(One).myattrib.converter,
    )

Typing aside, writing a helper that gives you something like evolve_attrib(attr.fields(One).myattrib, default=2) would be trivial and maybe there's more way to make it more ergonomic? The data is all there for you to use.

Another detailed description in #698, which is a duplicate.

So I guess I could be convinced to add something like

@attr.define
class Two(One):
    myattrib = attr.field_evolve(default=2)

That would also keep myattrib in the same order which would solve #707.

However:

• I find it hard to find the motivation to implement it.
• @euresti might correct me, but it sounds like a pretty big chunk of work in mypy? And so far they haven't even merged his NG API PR. :(((

Over at #829 we've come up with a somewhat clunky but magic-free approach of allowing to evolve Attributes (already in) and then convert them to fields/attr.ibs.

In your case that would look like this:

@attr.define
class Two(One):
    myattrib = attr.fields(One).myattrib.evolve(default=2).to_field()

I do realize it's a tad verbose, but it's a lot clearer with less indirection than what was proposed so far and would only require us to impolement to_field for Attribute classes.

Great. Many thanks for the follow up! I'll check it out!

To confirm, the above does not exist in the current version yet, correct?

correct, it does not.

The above would be great to have - not only for modifying fields of sub-classes but also for "de-duplicating defaults" - when passing arguments down through multiple levels, as in #876. Not sure how possible this is with regard to attrs internals, but from an external perspective it would be seem more intuitive to have the syntax:

@attrs
class Two(One):
    myattrib = One.myattrib.evolve(default=2)

Re #829 Here's what I'm doing...

from attr import define, field, fields, validators, make_class

@define
class One:
    myattrib: int = field(
        default=1,
        validator=validators.instance_of(int),
        converter=int,
    )

def create_subclass(name, base, **kwargs):
    def gen_fields(*args):
        for field in args:
            if field.name in kwargs:
                yield field.evolve(default=kwargs[field.name])
            else:
                yield field

    def reset_defaults(cls, fields):
        return list(gen_fields(*fields))

    return make_class(name, {}, bases=(base,), field_transformer=reset_defaults)


Two = create_subclass('Two', One, myattrib=2)

In [31]: fields(One)
Out[31]: (Attribute(name='myattrib', default=1, validator=<instance_of validator for type <class 'int'>>, repr=True, eq=True, eq_key=None, order=True, order_key=None, hash=None, init=True, metadata=mappingproxy({}), type=<class 'int'>, converter=<class 'int'>, kw_only=False, inherited=False, on_setattr=None))

In [32]: fields(Two)
Out[32]: (Attribute(name='myattrib', default=2, validator=<instance_of validator for type <class 'int'>>, repr=True, eq=True, eq_key=None, order=True, order_key=None, hash=None, init=True, metadata=mappingproxy({}), type=<class 'int'>, converter=<class 'int'>, kw_only=False, inherited=True, on_setattr=None))

a quick note to myself, that the implementation needs to take into account make_class (cf #1074).

I've implemented evolve_field in one of my codebases by subclassing _CountingAttr and using a custom field transformer (probably not how you want to do it here in upstream), and one thing I'd like to point out is that it seems natural to have evolved fields stay at the same index as the original field rather than go to the end. E.g.

@define
class A:
    x: int = 0
    y: int = 1

# attrs order: x, y

@define
class B(A):
    x: int = evolve_field(default=42)

# attrs order: x, y

@define
class C(A):
    x: int = 42

# attrs order: y, x

Notice how if you simply redefine the x attribute as in C, the order of init parameters is swapped, which may be confusing when used with inheritance. However, in B, evolve_field (which can only be used with inheritance) the order is maintained, keeping the same interface as in the parent class.

Another issue that came up during my implementation was that some sanity checks like "no attrs without a default following an attr with a default" happen before the field transformer is run, so the field transformer has no chance to fix the issues. You may not run into this since it may not be implemented using a field transformer like I did.

I've implemented evolve_field in one of my codebases by subclassing _CountingAttr and using a custom field transformer (probably not how you want to do it here in upstream), and one thing I'd like to point out is that it seems natural to have evolved fields stay at the same index as the original field rather than go to the end. E.g.

@jamesmurphy-mc how were you able to implement this?

My use-case is similar to yours. Preferably, I would like to implement something like what you have or pass a new field definition altogether that can overwrite the existing field while maintaining order.

@define(kw_only=True)
class A:
    x: int = field(default=0)
    y: str = field(default="1")
    z: str = field(default="2")

# attrs order: x (int), y (str), z (str)


# using your approach
@define(kw_only=True)
class B(A):
    x: str = evolve_field(type=str, default="0")

# attrs order: x (str), y (str), z (str)


@define(kw_only=True)
class C(A):
    x: str = field(default="0")

# attrs order: x (str), y (str), z (str)

@jamesmurphy-mc how were you able to implement this?

It was a mark and sweep approach, using evolve_field to mark and a custom transformer calling in a @define wrapper to sweep.

Just like field, evolve_field would return a _CountingAttr, but instead of the base class, it would return this custom subclass that had some metadata about what fields are being evolved. We used our own @define that called the attrs one with some special stuff including a custom transformer, and this custom transformer would look for the evolve metadata and handle it accordingly by traversing the MRO and finding the old field from the super class and then applying the changes from the evolve metadata.

Changing the type of an attribute in a subclass is very tricky.

Changing the type to something completely incompatible (like str to int) should never be allowed since it breaks the Liskov substitution principle. Changing the type of a field to a subtype (like changing int to Literal[1]) should only be allowed for frozen classes.

Defaults, aliases and kw-only status should be safe since constructors don't obey the LSP.

You could argue for a consenting adults approach where we allow anything at runtime, but apply restrictions in Mypy. Still seems like a footgun.

Hey @Tinche, fully get the LSP argument for str -> int, but can you elaborate why frozenness would be required for a change like int -> Literal[1]? 🤔

I agree that there is probably no obvious answer to this entire evolving fields discussion. However, I wonder what a reasonable/pragmatic alternative would look like for the not-so-uncommon pattern where you want your types in the subclass to be more specific.

Specifically, how would you avoid a situation like

from attrs import define

@define
class BaseSettings: ...

@define
class SpecialSettings(BaseSettings): ...

@define
class Base:
    settings: BaseSettings

@define
class Special(Base): 
    settings: SpecialSettings

I guess one option is use Generics for the base class, but this has a different flavor to it. Would be happy if you could share your thoughts 🙃

can you elaborate why frozenness would be required for a change like int -> Literal[1]?

Sure. Imagine this:

@define
class ClassA:
    a: int

Now, imagine a very simple and innocent function, like this:

def innocent(a: ClassA) -> None:
    a.a += 1

All good so far, right? Now for the final act of the show, imagine:

@define
class ClassB(ClassA):
    a: Literal[1]

innocent(ClassB(1))

It's a variance issue, the same as with list vs Sequence. Variance is a term associated with generics, so that be a clue of what we're dealing with in reality ;)

Thanks @Tinche, much appreciated. Makes sense, indeed.

Still, any thoughts on my example above? What's your take on it, i.e. how would you avoid having to copy-paste the entire field definition in the subclass just to change the type annotation?

Try something like this?

from attrs import define


@define
class BaseSettings: ...


@define
class SpecialSettings(BaseSettings): ...


@define
class Base[T = BaseSettings]:
    settings: T


Special = Base[SpecialSettings]

Yeah, already thought about using Generics for this. And while it works (and probably is a clean solution), I still wonder: is it possible to avoid using the default type in a certain local context? For example, using your code above, I can't do something like:

lst: list[Base] = [Base(BaseSettings()), Special(SpecialSettings())]

since the default type would be used, which gives:

error: List item 1 has incompatible type "Base[SpecialSettings]"; expected "Base[BaseSettings]"  [list-item]

Of course, one could omit then default from the class definition but then ... well ... there would be no default 🙃 So what is the solution here to enable both: a default + a correct list type?

Since Special is just a static type alias here, what about:

lst: list[Base] = [Base(BaseSettings()), Base(SpecialSettings())]

?

Doesn't work unfortunately because – and I forget to mention this – Special is not just an alias but really has some additional stuff defined, e.g.

@define
class Special(Base[SpecialSettings]):
    special_attribute: int = 0