Opened 7 years ago

Closed 5 years ago

Last modified 5 years ago

#13206 closed Bug (fixed)

Model does not call super __init__

Reported by: George Vilches Owned by: nobody
Component: Database layer (models, ORM) Version: master
Severity: Normal Keywords: __init__ super Model
Cc: mmitar@…, tim@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

In the Django Model class, super(Model, self).__init__ is never called. Since Django inherits from object, there is no backwards-compatibility issues by calling super.__init__, and it enables multiple-inheritance/mixins to work as expected in standard Python classes.

Attachments (1)

django-model_init_super_r12847.patch (1.3 KB) - added by George Vilches 7 years ago.
Enables support for Model.init super, against r12847.

Download all attachments as: .zip

Change History (11)

Changed 7 years ago by George Vilches

Enables support for Model.init super, against r12847.

comment:1 Changed 7 years ago by Russell Keith-Magee

Needs documentation: unset
Needs tests: unset
Patch needs improvement: unset
Triage Stage: UnreviewedAccepted

comment:2 Changed 6 years ago by Russell Keith-Magee

milestone: 1.3

comment:3 Changed 6 years ago by Alex Gaynor

Resolution: fixed
Status: newclosed

(In [15317]) Fixed #13206 -- call super().init() in Model.init to allow mixins to do things there.

comment:4 Changed 6 years ago by Alex Gaynor

(In [15320]) [1.2.X] Fixed #13206 -- call super().init() in Model.init to allow mixins to do things there. Backport of [15317].

comment:5 Changed 5 years ago by alaa

Resolution: fixed
Severity: Normal
Status: closedreopened
Type: Bug

there is backwards compatibility issues with this change, init for sibling class in cases where there is multiple inheritance is now called when it wasn't called before, and called at a specific point in model construction.

code that used multiple inheritance with models would have had to explicitly call init or assume it never gets called, so I can't see how u consider this backward compatible.

that's a major change to introduce in a bug fix release (1.2.5), it is also an undocumented change.

it doesn't help with situation where there are more than two classes involved in the multiple inheritance, always calls the constructor at the end of the function when there are situations where it might be better called at the start, so I'm not sure it is better than letting client code explicitly call the constructor if required.

it also assumes init in all classes involved requires no arguments (should at least pass *args, kwargs).

comment:6 in reply to:  5 Changed 5 years ago by Carl Meyer

Resolution: fixed
Status: reopenedclosed

Replying to alaa:

that's a major change to introduce in a bug fix release (1.2.5), it is also an undocumented change

it also assumes init in all classes involved requires no arguments (should at least pass *args, kwargs).

These are reasonable concerns, IMO, particularly the latter -- but reopening this ticket is the wrong place to raise them. The issue in this ticket has been fixed - if there are problems with the fix, we need another ticket that describes that problem. Or better, since I suspect some design judgment calls will be needed, bring it up for discussion on the django-developers mailing list.

comment:7 Changed 5 years ago by Mitar

Cc: mmitar@… added

comment:8 Changed 5 years ago by Tim Child

Cc: tim@… added
Easy pickings: unset

I agree with alaa, is there a new ticket that has been created for this new issue?

comment:9 Changed 5 years ago by dmrschmidt

UI/UX: unset

Just found this ticket here and I actually DO have an issue with that one. I am using Mixins in some classes, passing them 4 arguments in their init. This now results in
TypeError "init() takes exactly 4 arguments (1 given)". So will there be a fix for this in 1.2.X?

comment:10 Changed 5 years ago by Jacob

milestone: 1.3

Milestone 1.3 deleted

Note: See TracTickets for help on using tickets.
Back to Top