I am wondering if this can feel more natural (i.e. hide the detail as much as possible) if we do this with Mirror and just let you declare a normal class:

struct CustomNetwork: PythonClass {
  static var superclass = [torch.nn.Module]
  var __init__ = PythonInstanceMethod { `self`, arguments in
  }
  var forward = PythonInstanceMethod { `self`, arguments in
  }
}

let network = MAGIC_FUNCTION(CustomNetwork.self)(init_arguments)

The MAGIC_FUNCTION can look like something:

  var mirror = Mirror(reflecting: type)
  var name = type.description (??)
  for child in mirror.children {
  }

Alternatively, the API can use some kind of builder pattern:

let CustomNetwork = PythonClass(name: "CustomNetwork", superclasses: [torch.nn.Module]).defineMethod("__init__", { self, arguments in }).defineMethod("forward", { self, arguments in }).build()

Obviously I am out of depth here, but just want to enumerate other design options available for supporting subclasses.

@liuliu I have doubts that Mirror is that powerful, although I did think about it. That would be awesome, so please prove me wrong!

A function builder API sounds cool, but it’s something that will build on what we have now. It could be a second initializer. I’m not going to spend much more time on this, but please put your ideas into action if you have the time.

For defineMethod, properties are also members, as well as initializers. Your last idea is a little too much for PythonKit, which keeps things as simple as possible.

@pvieito I haven't added proper tests for this yet. Should I add them before merging?

@philipturner Yes, please!

I got test #2 figured out. Subclassing a custom class requires a different syntax than super().__init__(params), but that isn't going to be documented. You'll see what I'm talking about when I update my branch, then we can discuss if it's a concern.