Hi,
I'm jumping in the discussion as I've tried - hard - to do something similar in
the past.
However, I'll second what has been said: mixins should be on the left side.
Is there a reason your code can't be similar to:
#class View(object):
# def __init__(self):
# print "View init"
class SomeMixin(object):
def __init__(self):
super(SomeMixin, self).__init__()
print "SomeMixin init"
class MyView(SomeMixin, View):
def __init__(self):
print "MyVIew init"
super(MyView, self).__init__()
MyView()
The reason why the mixin has to be left to the view isn't obvious in your
example.
If you need the super for the __init__ it's likely that you'll need it for
other functions. As opposed to __init__ those functions will not exist in the
object class. Therefore you'll end up with testing if the super has the
function or not before accessing it because it'll depend on the mixins order.
Regards,
Xavier.
Le 2 oct. 2013 à 23:56, Glin <g...@seznam.cz> a écrit :
> Sorry, I had problems to get to my google account, but finally I'm here :).
>
> I wrote to the ticket meanwhile, but you probably not in CC, so I paste it
> here, too:
>
> Having this example:
> class View(object):
> def __init__(self):
> print "View init"
> #super(View, self).__init__()
>
> class SomeMixin(object):
> def __init__(self):
> print "SomeMixin init"
> super(SomeMixin, self).__init__()
>
> class MyView(View, SomeMixin):
> def __init__(self):
> print "MyVIew init"
> super(MyView, self).__init__()
>
> MyView()
>
> With the commented line in the View class, the method SomeMixin.__init__ is
> not called, because mro chain is broken, that's the reason why I filled the
> ticket.
> Practical use - for exemple in current mixins, there are instance attributes
> which are not defined in __init__, which is bad, code is harder to read when
> new attributes pop up on unusual places, every checker like pylint displays
> warning like:
> W:127,8:ModelFormMixin.form_valid: Attribute 'object' defined outside __init__
>
> So in ModelFormMixin, there should be __init__ which defines 'object'
> attribute (self.object = None), which is IMHO more than good practice.
> Also having attribute 'object' in __init__, we could avoid ugly constructions
> like now (also in views/generic/edit.py):
> elif hasattr(self, 'object') and self.object is not None:
>
> And that's example in Django itself, I bet there could be lot more in various
> cases of other developers views/mixins, which are hurt by broken mro chain.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/fb4b4508-99bf-4156-bbdd-f9ee4a957bbd%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/1EEE9B02-9A6D-4318-8F49-7CF6A9F62481%40linovia.com.
For more options, visit https://groups.google.com/groups/opt_out.
