Possibility to call custom initialization

[ilevkivskyi]

Imagine a situation with this class:

class BigClass:
    def __init__(self, x, y, z, t, w, parent):
        self.x = x
        self.y = y
        self.z = z
        self.t = t
        self.w = w
        self.tmp = TempStorage()
        self.tmp.link(parent)
    ...
    def __repr__(self):
    # other boilerplate

It should be possible to refactor this into:

@auto
class BigClass:
    x: int
    y: int
    z: int
    t: int
    w: int
    def initialize(self, parent):  # We can choose other name, maybe name of the class?
        self.tmp = TempStorage()
        self.tmp.link(parent)

A simple way to achieve this is to add code like this at the end of generated __init__:

def __init__(self, <inserted args>, *extra_args):
    ...
    if hassattr(self, 'initialize'):
        self.initialize(*extra_args)

[hynek]

JFTR attrs has a similar feature called __attrs_post_init__(self) and I would suggest to use a dunder method too, otherwise it looks like it’s part of a public API.

There’s really no reason to special-case extra_args though. Just let them put on self get them from there. It’s more straight-forward, easily understandable, and I doubt the complexity around handling extra_args is worth it. Especially because it would come with some asterisks.

[ilevkivskyi]

I would suggest to use a dunder method too, otherwise it looks like it’s part of a public API

But it actually can be part of public API. Also dunder methods might look scary to users. Possible problem with using non-dunder method name is an occasional name clash. Possible solutions are:

• Using a keyword (name to be discussed):

  from classtools import auto_fields
  
  @auto_fields(hash=True, setup='initialize')
  class BigClass:
      x: int
      ...
      def initialize(self, parent):
          self.tmp = TempStorage()
          self.tmp.link(parent)

• A special decorator (name to be discussed):

  from classtools import auto_fields, on_create
  
  @auto_fields(hash=True)
  class BigClass:
      x: int
      ...
      @on_create
      def initialize(self, parent):
          self.tmp = TempStorage()
          self.tmp.link(parent)

  With this syntax it is possible to call multiple initializers (typically in the case where they are parts of public API that needs to be called on creation).

In both cases a user can start the name with a single underscore if this is not a part of public API.

There’s really no reason to special-case extra_args though. Just let them put on self get them from there. It’s more straight-forward, easily understandable, and I doubt the complexity around handling extra_args is worth it.

I am not sure what do you mean by "just let them put on self"? The only way to put something on self is to add a field for this. I could imagine situations where this may be unwanted. I have seen situations where __init__ has some flags that don't end up on self. Without extra_args there will be no way of adding some flags to generated __init__.

Also I don't think it will be difficult to add extra_args, especially that manual code generation is used. @ericvsmith What do you think?

[hynek]

For reference, we had an epic bikeshed on that topic and decorators came up too: python-attrs/attrs#68 – I seem to remember that a well-known method had the least downsides – especially re subclassing.

---

Re extra_args

I’m using attrs syntax for simplicity here now, but you could do this:

@attr.s
class C:
    x  = attr.ib()
    parent = attr.ib()
    tmp = attr.ib(init=False)

    def __attrs_post_init__(self):
        self.tmp = TempStorage()
        self.tmp.link(self.parent)

The advantage is that it doesn’t introduce any new concepts. If you don’t want that field to be there, make it private using an underscore. OTOH I learned the hard way that trying to pander to every single use case under the sun leads to regret and tears. :) You can always write your own __init__.

Also this seems like a feature that can be added later if really necessary.

[ilevkivskyi]

Indeed a special name looks most simple, but I don't like a dunder for this purpose. Beginners tend to think about dunders as being "magic" (although they are not) and therefore hesitate to use them.

[gvanrossum]

But this is magic -- just as magic as `__init__`, which they will still have to use. I would teach beginners plain classes first, and then point out they can save some work if they are okay with a certain pattern, by using `@dataclass`. So the dunder doesn't bother me.

…

On Tue, Jun 6, 2017 at 10:25 AM, Ivan Levkivskyi ***@***.***> wrote: Indeed a special name looks most simple, but I don't like a dunder for this purpose. Beginners tend to think about dunders as being "magic" (although they are not) and therefore hesitate to use them. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#13 (comment)>, or mute the thread <https:/notifications/unsubscribe-auth/ACwrMnavegr-HZ4mzTyPdl8NVCLhfMRbks5sBYucgaJpZM4NwTB5> .

-- --Guido van Rossum (python.org/~guido)

[ericvsmith]

@hynek: that really was a mega-thread! Thanks for the pointer.

From reading the thread, I think an optional well-known entry point like __attrs_post_init__ does make the most sense. And do I understand correctly that it's left to the class authors to call super().__attrs_post_init__ if they want to? That seems like a good decision. As the arguments to the post init function never change, you don't have the same problem as trying to call __init__ through super().

So, I propose that (subject to name changes) we have the generated __init__ call __dataclass_post_init__, if one exists.

As far as extra parameters go: I'm not sure we can add it later, without changing the __dataclass_post_init__ function signature, which again runs in to problems with super() calls.

[gvanrossum]

I'll leave this for Eric to decide.

[hynek]

And do I understand correctly that it's left to the class authors to call super().__attrs_post_init__ if they want to?

Yes, because everything else would end up in wonky guesswork. People can also call super().__init__() – that was one of the main original reasons why we added it in the first place (I think using PyQt was one of the use cases).

[ericvsmith]

I've implemented a parameter-less __dataclass_post_init__ function, that is called if present.

I opened issue #17 to decide if we want/need to pass parameters to it.