Also just a note that I'll soon be away for vacations until october, I just want to get that ball rolling and gather feedback in the meantime.

@BadSingleton is there a way to provide that functionality without bringing the NonSerializedTypeBuilder into Python.NET? E.g. can we allow user to override the serializer somehow, and you guys would be able to keep this code inside Unity or as a new subproject like pythonnet/unity-serializer?

Also, can you describe the approach in more details?

@lostmsu I think the serializer was meant to be overridable in the first implementations of the serialization. I think I recall @amos402 saying something about the need for users to implement their own. If it becomes overridable we probably can keep it outside of this repo (just need to make sure with some order of initialization things)

The idea was to ensure that the presence of a non-serializable object in the graph wouldn't throw an exception, therefore corrupting the whole shutdown process and causing crashes on domain (un)load. As sometimes those objects are outside of our control, we can't modify them and/or avoid easily to serialize them (and/or the users of our APIs may be passing a Unity object that is not serializable). After a few google searches I found out that serialization surrogates could be used to serialize objects not marked [Serializable]. Since these objects are not meant to be serialized, but they're in the object graph that is being serialized, we serialize the type, not the object. When deserializing, there are two possibilities:

1. The object can be derived from, and we add _NotSerialized suffix to the class name. If it is, every method and property (get and set) are overridden by a simple function that throws a NotSerializedException (the inspiration for the exception message comes from PyQt. Those who knows, know the pain.). Fields are left null.
2. The object cannot be derived from (private, internal, ...). Not much to do here, except returning a null reference.

When serializing a derived _NotSerialized class, we serialize the base class to avoid having _NotSerialized_NotSerialized_... looping.

Ignore the part of the previous comment about the serializer not being overridable, I misremembered the code, it is overridable.

It seems that this code can be abstracted out of this repo with:

1. Having a public post stash and pre restore hooks
2. Exposing a wrapper for PyCapsule and maybe PyMem (though I think it can be replaced with Marshal.AllocHGlobal)
3. Replacing FormatterType property with FormatterFactory
4. Exposing MaybeType

Worst case, MaybeType is easily re-implementable. I'm not sure about exposing it.