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

from python-pyfields.

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.

from python-pyfields.

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

from python-pyfields.

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

from python-pyfields.

Closing - other tickets have been created for each aspect

from python-pyfields.