[RFC] Quo vadis re: classes

[hynek]

Time for more existential questions.

Currently attrs has involuntarily two ways of attaching its methods. Both come with certain problems and there are (or are suspected) remedies.

We should really discuss this once and for all and transition towards one approach. Here’s what I’ve got:

We tack our methods to the existing class body.

Default behavior.

Problems

• Edge cases may appear because Python runtime is confused. As far as I can tell, so far only the inconsistence in the behavior of __eq__ and __hash__ (cf. ) is a real problem so far.

Remedies

• Catch all edge cases. So far it’s only one that popped up so it seems manageable?

We create a new class in @attr.s and return it instead of the original

Happens if slots=True. This has the upside that we create a brand new class that doesn’t change so no edge cases are to be taken care of.

However, the user gets a different class, which comes with its own set of problems.

Problems

• super() doesn’t work. TypeError when using super() and slots=True #102

Solutions

• ctypes voodoo

---

At this point, I find the confusingly broken super() worse than the default approach so I would prefer if we found a way to cheat __slots__ into existing classes and I’m not afraid of using C or meta programming to get there.

---

If others have more problems/solutions, I’ll happily add them.

[Tinche]

The problem with tacking methods onto an existing class is we can't add "slotness" to an existing class, right?

I'm more interested in the user-facing API than the internals; there's going to be filth under the hood either way. All other things being the same, I'd prefer to keep the dirt on our side, and let users frolic in their ignorance of what we're doing in their name.

I'm assuming adding slotness with a metaclass would require users to actually specify that metaclass? Like this:

@attr.s
class C(metaclass=SlotsMetaclass)
    a = attr.ib()

Personally I find the current approach of attr.s(slots=True) very nice since I can do things like

def profile(cl):
    return attr.s(frozen=True, slots=True)(cl)

@profile
class C:
    a = attr.ib()

and it's nice and elegant. Also does using a metaclass for slotness means users can't use another metaclass?

[hynek]

I absolutely agree on the filth being on our side.

My fear is just that the filth might just…break eventually? It seems like playing with internals that may also have other side-effects like confusing PyPy's JIT etc. :|

I really don’t know. 😖

[hynek]

So I tend to go with “cheating the interpreters and return new classes like slots=True” again.

Unless someone voices disagreement (@glyph?) we’ll ship the hacks in 17.3.0 and eventually move there in all cases.

[Tinche]

My fear is just that the filth might just…break eventually? It seems like playing with internals that may also have other side-effects like confusing PyPy's JIT etc. :|

I know this fear very well :) Mentally I counter it by saying to myself "we're a volunteer open source project, we're doing the best we can, if we do something wrong or paint ourselves into a corner with a wrong decision oh well, we'll fix it and try again" :)

👍 for returning new classes. I can put together a fix for #102 when I have some time and we can take it from there.

[hynek]

You've got any timeline in mind? Seems like your plate keeps getting fuller. :)

[hynek]

Since this is settled now, we have to figure out a road map on how to make it “always new class”.

That’s a breaking change re: at least the hashing thingie, so we’ll have to be careful.

[glyph]

What is the plan for being careful?

[hynek]

What I meant is that we won't do the bandaid thing again and try to find a way to do some kind of deprecation cycle.

Maybe make it an attr.s Option so we can raise a DeprecationWarning?

[hynek]

So we’ve just ran into more problems re metaclasses and I’m afraid taking the “always create new class” is just not practical. We’d break wayyy to much stuff on the way.

So the question is: what can be done instead?

• find some clever hack to get __slots__ on existing classes
• @RonnyPfannschmidt mentioned metaclasses but I know nothing about how they could help

[RonnyPfannschmidt]

sanely using meta-classes would require to inherit from a class that is a instance of them
since they are the then completely involved in the class construction, there is no need to modify a class, all preparation can be done before constructing the class and stuff like super() would just work as far as i understood (the class would never be taken away from under it)

[Tinche]

The original problem with metaclasses is that they aren't composable, right?

Our current problem is replacing the class won't allow our users to use the metaclass they want. But switching attrs to a metaclass approach again won't allow our users to use the metaclass they want :)

[RonnyPfannschmidt]

true - but when using attrs, many things you do with metaclasses are displaced anyway

for example if you use a sqlalchemy declarative metaclass, you dont want any attrs behaviour

so i dont see enabling metaclass based inheritance for stuff like correct __slots__ support and correct super() a bad thing

[Tinche]

Unfortunately, I think the approach of recreating the class is fundamentally incompatible with metaclasses. We might make it work in some cases but not in all cases.

So maybe we can brainstorm a better API for slots, and I can replace our black magic with different black magic so we set slots before the class is finalized. Then we would never have to replace the class.

Should we open a new issue to talk about different slots APIs?