[RFC] Inconvenient defaults?

[hynek]

As part of “Projectimport attrs” (see also #408) we get a unique opportunity to change default options/behaviors that grew over the years but couldn't be fixed due to backward-compatibility restrictions.

The rough plan is create a new, friendlier API on top of @attr.s and attr.ib() that won't go anywhere.

The following is cast in stone:

• auto_attribs=True
• consistent (Python 3-style) hashing behavior on every Python version
• MRO vs. inherited attributes #428

The following would be really nice to have:

• Add a convenience flag for upcalling on Exception subclasses #368 but it might need too much thinking/research

What else is bugging you?

---

One thing that I just can't make up my mind is related to #223: should we make slots=True the default? I’m quite confident that in 99,9% of cases it's the right thing to do and will guide people to write better classes.

However on the other hand, our approach of rewriting classes breaks in certain scenarios, usually involving metaclasses.

So the question is, whether we want to tolerate a higher rate of bogus bug reports/help requests or make the default case nicer?

I welcome your input.

---

Finally a controversial idea: we could make import attrs Python 3 only. There isn't much baggage we'd get rid of but there is some and 2020 is less than a year ahead. It would also allow us to embrace enums as part of our API.

[sfermigier]

"we could make import attrs Python 3 only." -> +1.

"It would also allow us to embrace enums as part of our API." -> That would be awesome.

[berislavlopac]

I absolutely agree with your point on slots=True, but I would recommend not making it the default. I'm always surprised by how many people have no idea that this amazing feature exists; you need to at the very least explain in the documentation what it is anyway, so it can be used to recommend its use and guide people to write better classes. 🙂

I'm also in favour of Python3-only import attrs.

What else is bugging you?

A question: My main issue with attrs has always been its decorator-based syntax and inability to instantiate using __init__. To be clear, it's my personal preference and not a general opinion on How Things Should Be Done [TM], but I've always liked the subclassing approach found in e.g. schematics. Also, I've often explained the concept of data classes (regardless of the implementation) as "ORM without the R", as it maps nicely with people's experience with Django and others. So I just have to ask, it there a possibility to have an optional method of implementing attrs as a parent/abstract class and/or a mixin?

Thanks for all the amazing work!

[hynek]

So I just have to ask, it there a possibility to have an optional method of implementing attrs as a parent/abstract class and/or a mixin?

No, but you could probably use metaclasses and our programmatic interface (make_class) to build it yourself?

[ncoghlan]

In a world of AWS Lambda and other RAM-second based billing systems, making "slots=True" the default will literally save people money (since it uses less RAM, and avoids pointless dict creation for each instance).

If it fails, then folks are likely to get noisy exceptions that a few asked-and-answered questions on Stack Overflow will teach them to resolve with "slots=False".

[bskinn]

If it fails, then folks are likely to get noisy exceptions that a few asked-and-answered questions on Stack Overflow will teach them to resolve with "slots=False".

Could even seed SO with a couple of self-answered Q&A covering common error cases where slots=False is the fix.

[hynek]

If it fails, then folks are likely to get noisy exceptions that a few asked-and-answered questions on Stack Overflow will teach them to resolve with "slots=False".

I tend to agree; it just goes a bit against attrs’s principle of “just adding some stuff” to your classes.

[jml]

My feelpinion: frozen=True should be the default. Probably the option should be renamed to mutable, so you say mutable=True for when you know what you are doing.

[bskinn]

My feelpinion: frozen=True should be the default. Probably the option should be renamed to mutable, so you say mutable=True for when you know what you are doing.

Disagree here. frozen=True only works for me in situations where (1) the entire contents of all instances will be known at instantiation-time in all cases, and (2) where no derived/calculated members will be needed (i.e., where @propertys are sufficient for all derived members because the calculations are fast).

I use attrs classes a lot in my data analysis work, and often I'll have something expensive I need to do with the arguments passed in at initialization. I absolutely want to do that expensive thing exactly once for each instance, and AFAIK I have to do it as something like:

@attr.s(slots=True)
class Foo:

    input_var = attr.ib()
    expensive_derived_var = attr.ib(init=False)

    def __attrs_post_init__(self):
        self.expensive_derived_var = self.calculate_expensive_thing()

    def calculate_expensive_thing(self):
        ...
        {expensive stuff with self.input_var}
        ...

With frozen=True, I can't set self.expensive_derived_var in __attrs_post_init__.

That being said, I have no idea whether my needs here at all represent the majority of use-cases.

[hynek]

I love myself some value types but frozen=True ain’t happening. :)

It just doesn’t fit Python too well. But IIRC we’ve decided on an own function for it?

[berislavlopac]

I agree with frozen=False as the default, but kinda like using the term mutable, unless there is a significant difference between the meaning in attrs and Python in general. So I guess I would vote for the mutable=True as default.

Oh, and I think that @bskinn's argument against frozen=True equally applies to slots=True; I still think they should both be off by default. Unless I'm mistaken, slots applies to the attributes defined via attrs and no additional attributes can't be added, is that right?

[berislavlopac]

No, but you could probably use metaclasses and our programmatic interface (make_class) to build it yourself?

Possibly, will look into it.

[hynek]

The reason why it's called frozen is because that's how we call these things in Python (frozenset etc) and I don't want to open a new nomenclature out of purity. I've seen good things fail too often because of the stubbornness of its maintainers to be a good Python citizen.

And yes, slots=True prevents new attributes and you really shouldn't add ad-hoc attributes so that's a feature. If you need it, you can always say slots=False and the class has a warning attached to itself, that the attribute list is not comprehensive.

[jml]

we’ve decided on an own function for it?

Did we? Where can I read about that?

[hynek]

Where can I read about that?

#408 (comment)

It's gonna be @attrs.define and @attrs.frozen. Depending on https://hynek.me/about/#gratitude I might add an attrs.mutable alias for define. ;)