[Python-ideas] JavaScript-Style Object Creation in Python (using a constructor function instead of a class to create objects)

[Sven R. Kunze]

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.


Regards,
Sven


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 <srkunze at mail.de
>>> <mailto:srkunze at mail.de>> wrote:
>>>
>>>     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.
>
> Eric.
>