Opened 14 years ago

Closed 13 years ago

Last modified 13 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: dev
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 14 years ago.
Enables support for Model.init super, against r12847.

Download all attachments as: .zip

Change History (11)

by George Vilches, 14 years ago

Enables support for Model.init super, against r12847.

comment:1 by Russell Keith-Magee, 14 years ago

Triage Stage: UnreviewedAccepted

comment:2 by Russell Keith-Magee, 14 years ago

milestone: 1.3

comment:3 by Alex Gaynor, 13 years ago

Resolution: fixed
Status: newclosed

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

comment:4 by Alex Gaynor, 13 years ago

(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 by alaa, 13 years ago

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).

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

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 by Mitar, 13 years ago

Cc: mmitar@… added

comment:8 by Tim Child, 13 years ago

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 by dmrschmidt, 13 years ago

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 by Jacob, 13 years ago

milestone: 1.3

Milestone 1.3 deleted

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