Class methods on model instances (why?)
Classmethods operate on the table. Instance methods operate on the rows. Class represents table, instance represents row. It is just an inconvenient fact of python's `classmethod` decorator that you can call classmethods from an instance. I could write a special decorator that prevented this, e.g. `classonlymethod` but I don't think it's worth the time and more Pythonic anyways.
 That makes sense, I had considered using a special decorator myself in the past but it always felt like a bit too much magic, and made it confusing for anyone new to the code. This has given me some food for thought anyway, thanks again for the quick reply.

As per [documentation](1), models have class methods such as `get_or_create`, which can be used to create a new model instance. Merging together object and objectset methods doesn't feel like a clean abstraction (imho), e.g. the ability to `get` another object which is unrelated to the object we're calling `get` from. For example;

```
u = User.get_or_create(name='amber')
u.get_or_create(name='jessica')
```

Previously I've always followed the design approach of separating object and objectset, similar to the approach that [Django](2) uses. For example;

```
u = User.objects.get_or_create(name='amber')
```

Could you give a brief explanation behind your reasoning for having methods such as `get_or_create` as class methods on the object, rather than a method on a manager class (such as `User.objects`)? Is this a legacy design thing that won't change due to backwards compatibility, or is there some technical merit behind this approach? 

This is more for my own knowledge/learning, as it's left me wondering if my design principles are flawed or if I've overlooked some detail, so your insight would be appreciated.

Many thanks
