Would it be possible to support __slots__?

[Tinche]

I don't know if this would even be technically possible, but it'd still be nice to have. I'm personally not that interested in the efficiency gains (although it'd be nice), but I'd like for exceptions to pop up when non-existent attributes are assigned to attrs instances (just got bitten by this making one of my tests fail).

[hynek]

I’m afraid not trivially. Setting __slots__ on class attributes makes them constant…

I think there might be a way via descriptors but I hadn’t time to investigate any further.

[Tinche]

I've been playing with maybe implementing this. I think I might have something; I'll have to parametrize the tests before I know whether it works.

I think the point of __slots__ is lost if you inherit from a class that doesn't use slots - as far as I can see there are no size gains (or they are much smaller) and arbitrary attributes can be assigned. I'm thinking throwing an error if we detect a non-slots class in the class hierarchy when creating?

So my working idea is to create a new class in wrap (https:/hynek/attrs/blob/master/src/attr/_make.py#L185) and adapt that. The problem here is __slots__ doesn't work with class variables.

>>> class A():
...     __slots__ = ("t")
...     t = "test"
...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: 't' in __slots__ conflicts with class variable

This is technically an API break for slots classes. (The docs for attr.Attribute state: "Instances of this class are frequently used for introspection purposes like: [...] Class attributes on attrs-decorated classes after @attr.s has been applied.")

There may be other edge cases since we're basically replacing one class with another, but these should be very rare and could be documented.

So my initial idea was to just add a slotskwarg to attr.s(), but maybe slot classes could be a separate thing? They need additional documentation, can't support the entire interface and are most useful with only other slots classes in the inheritance hierarchy.

Would appreciate your thoughts :)

[hynek]

Hm yeah replacing classes sounds really shaky but AFAICT, it’s the only way. They’d have to be something opt-in anyway, so I don’t see a problem here.

In any case, it would be a new type, new API so we have total freedom as long as stuff is documented. Especially stuff like putting limits on slots only on top of slots etc. One can always loosen restriction but once the genie is out of the bottle…

One thing to consider is how inheritance works out?

[Tinche]

I've got something brewing over here: https:/Tinche/attrs/tree/feature/slots

I've covered the simple stuff, adjusted some tests and added some new ones. Went with the following approach, since it seems natural and as you said slots are opt-in:

@attr.s(slots=True)
class MyClass(object):
    x = attr.ib()

It seems to work for simple cases.

Now to cover the more complex stuff, like ensuring more complex classes can be transformed into slotted ones correctly. I think I've changed my mind on putting explicit restrictions on inheriting from non-slots classes; this being Python (consenting adults) and the fact that it's possible in pure Python, I don't think we should ban it. It should just be well documented.

[hynek]

You’re not asking for feedback, are you? :) AFAICT you’ve implemented what we talked about so far.

[Tinche]

It's still early, this is me exploring. Feedback is always welcome though :)

[Tinche]

Alright, I've polished up the implementation a little and thrown a lot of tests (old and new) at it, and it seems to be working. Would you like me to make a pull request now?

Apart from reviewing the code, we can talk about how exactly would you like this documented.

[hynek]

Sure, PRs are free. :)

[hynek]

Fixed by you! \o/ :)