Just one additional word about mixins:
we've been inspired by Django's extensive usage of mixins for their class-based views, forms and model classes. For one, we defined more mixins for those classes (like UrlMixin for view classes), and for another we developed our own mixin infrastructure for domain-specific classes.
In the end, a lot of our top-level classes (the ones actually used as API etc.) look like plug'n'play + configuration:
class MyImportantThing(Mixin1, Mixin2, Base): url = 'blaa/asdf' next_foo = 234 special_model = User
For example in this case, "url" might be the config parameter for "Mixin1", "next_foo" for "Mixin2" and "special_model" is required/recognized by "Base".
As you can imagine, testing is also easier.
On 19.05.2017 06:31, Eric V. Smith wrote:
On 5/18/17 2:26 PM, Sven R. Kunze wrote:
On 17.05.2017 23:29, Ivan Levkivskyi wrote:
On 17 May 2017 at 20:09, Sven R. Kunze <email@example.com
class Foo(dictlike, tuplelike, simpleobject): attribute1: User attribute2: Blog attribute3: list def __my_dunder__(self): ...
As I understand this is more or less what is proposed,
Are you sure? Could you point me to the relevant messages where mixins are mentioned as a key part of the proposal? All I could find are message using the @decorator syntaxes.
We've been working with mixins successfully for years now and I can tell you that it's "just" a clever way of refactoring existing code in order to make it more accessible to other modules based on use-cases.
So, the best person to tell what pieces to factor out would be Stephan using his 4-point list. And of course other people using NamedTuple but frequently refactoring to "attr" or own class because NamedTuple just is too much (defines too much implicitly).
Could you point me to this 4-point list of Stephan's? I couldn't find anything in the archive that you might be referring to.