The __init__ topic

[smarie]

Several cases to support

1. user writes his own init entirely. This is already supported and he can set the fields correctly (or not, for the optional)
2. user writes his own entirely but not the type hints, doc and defaults (they have already been declared, why copying again). Support the case where he uses all, or some of, the fields as constructor arguments. (will not be fixed for now)
3. user writes his own but does not want to write all the argument names so he could use a special variable fields in the constructor, and anywhere in his constructor do fields.assign() or fields.init(). (fixed in #13 - @inject_fields)
4. user writes his own but wished object creation to be faster than the above. In that case (to benchmark though), we would be rather interested by some kind of a __post_init__ support like in @dataclass (fixed in 0.5.0 - @init_fields and make_init)
5. user wants fully automatic init creation (fixed in 0.5.0 - make_init)

In all these cases,

• The initialization order can be by default the order of appearance in the class. We could also add a init_after=<fields> argument to field() so that a field requiring other fields to be set before validation, converter or default_factory execution could be initialized afterwards. Another option would be to support a special way to declare that one of these three arguments depends on another field. (now in Support explicit init_after constraints so that fields can be initialized in another order than the default #23)
• we could optionally enable validation that all mandatory fields have been set at the end of init. That could be implicit or explicit (i.e. in use case 3. above, that could be done in fields.assign ?) (now in Generated init methods should or could check that all mandatory fields in the class have been set. #24)

[smarie]

In all the above scenarii, having a skip_validation option could be nice to get fast object creation routes. New issue #25

[smarie]

Possible ideas for the following example:

class Wall(object):
    height: int = field(doc="Height of the wall in mm.")
    color: str = field(default='white', doc="Color of the wall.")

feature 2

user writes his own __init__ entirely but not the type hints, doc and defaults (they have already been declared, why copying again). Support the case where he uses all, or some of, the fields as constructor arguments.

2a- most intuitive:

        @height.inject
        @color.inject
        def __init__(self, height, color):
            self.height = height
            self.color = color

pros:

• you can use autocompletion so it is fast to type the decorators
• you only declare the fields that you need

cons:

• many decorator lines
• you still have to type each attribute name in the init signature
• implementation will not be as efficient as a single decorator application since each decorator call can not know if it is the last or not

2b- fancy:

    @(height & color).inject
    def __init__(self, height, color):
        self.height = height
        self.color = color

Solves the "many decorator lines" issue but does not solve the rest.

2+ auto-assign

like in @autoargs from autoclass, whatever the above option we could add an argument to auto-assign the fields before init. And also allow after init ? Would probably not make sense.

[smarie]

Feature 3

user writes his own but does not want to write all the argument names so he could use a special variable fields in the constructor, and anywhere in his constructor do fields.assign() or fields.init().

        @inject_fields(height, color)
        def __init__(self, fields):
            fields.init()

pros:

• you can use autocompletion so it is fast to type the decorators
• you only declare the fields that you need, in the order that you like
• you control when init happens
• you can easily debug what happens during field initialization

cons:

• it does not seem possible to have @inject_fields work without arguments, or even with the class as argument, to say "use all fields from class", except if we allow introspection to be used. Indeed, at the time where the __init__ method is decorated, it is not yet bound to the class. EDIT actually it is possible: we can create a non-data descriptor on the class (this was inspired by this link).

[smarie]

feature 5

user wants fully automatic init creation

5a with decorator

@auto_init('height')
class Wall(object):
    height: int = field(doc="Height of the wall in mm.")
    color: str = field(default='white', doc="Color of the wall.")

pros

• a simple decorator, and "all fields" is easy to declare: decorator without arguments.

cons

• fields are referenced by name: no autocompletion if a particular selection needs to be made.
• decorator = a bit harder to debug and can be frightening

5b with decorator but fields declare if they are in init

@auto_init
class Wall(object):
    height: int = field(doc="Height of the wall in mm.", in_init=True)
    color: str = field(default='white', doc="Color of the wall.", in_init=False)

pros

• more compact decoration

cons

• I do not like the fact that the inclusion in init is a property of the fields. This will cause trouble in inheritance and mixin scenarii.

5c explicit method

class Wall(object):
    height: int = field(doc="Height of the wall in mm.")
    color: str = field(default='white', doc="Color of the wall.")
    __init__ = make_init(height, color)

pros

• compact
• autocompletion works if an explicit list or order needs to be provided
• this can probably be smoothly extended to support scenario 4 as well (a __post_init__ method or even any method using make_init(..., post=<method_post>) or make_init(color, my_post_init_method, height) so as to control precisely which part of the signature will go where)

I do not see much cons here

[smarie]

Closing - other tickets have been created for each aspect