I think it would be a good idea to put some work into making the clr module we provide as (backwards?) compatible with IronPython as possible.

This is the implementation: https://github.com/IronLanguages/main/blob/master/Languages/IronPython/IronPython/Runtime/ClrModule.cs

These are the public members

• Field bool IsNetStandard
• Methods AddReference{,ToFile,ToFileAndPath,ByName,ByPartialName}
• Methods LoadAssembly{FromFileWithPath,FromFile,ByPartialName,ByName}
• Methods Use (essentially a "generic" import, we could map it directly to that)
• Methods GetString (decode .NET byte arrays as Latin1)
• Methods GetBytes (encode a .NET string as a byte array in Latin1)
• Method SetCommandDispatcher (likely not applicable)
• Methods ImportExtensions (already requested by yours truly in Add support for clr.ImportExtensions #55)
• COM-related functions LoadTypeLibrary, AddReferenceToTypeLibrary, PublishTypeLibDesc
• Method GetClrType (Support clr.GetClrType() - as in IronPython #433)
• Method GetPythonType (takes a .NET Type object and returns the corresponding wrapped Python type)
• Method GetDynamicType (obsoleted, same as GetPythonType)
• Types Reference and StrongBox (Failure in function selection according to parameters #226)
• Decorator accepts (checks the argument types supplied to the decorated function, should be implementable in pure Python)
• Decorator returns (validates the result type of a function, also easy in Python)
• Method Self (always returns null?!)
• Methods Dir and DirClr (can both be mapped to dir in our case, I guess)
• Method Convert (tries to convert the object to the passed type by casting explicitly event.Control as foo in ironpython #611 )
• Methods Compile{Modules,SubclassTypes} (not applicable in our case)
• Method GetSubclassedTypes (returns a tuple of all types that have been subclassed, does not make sense in CPython)

We could add stubs for all of these, raising NotImplementedError and port over everything that is simple or makes sense to us.