I think it would be a good idea to put some work into making theclr 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

• Fieldbool IsNetStandard
• MethodsAddReference{,ToFile,ToFileAndPath,ByName,ByPartialName}
• MethodsLoadAssembly{FromFileWithPath,FromFile,ByPartialName,ByName}
• MethodsUse (essentially a "generic"import, we could map it directly to that)
• MethodsGetString (decode .NET byte arrays as Latin1)
• MethodsGetBytes (encode a .NET string as a byte array in Latin1)
• MethodSetCommandDispatcher (likely not applicable)
• MethodsImportExtensions (already requested by yours truly inAdd support for clr.ImportExtensions #55)
• COM-related functionsLoadTypeLibrary,AddReferenceToTypeLibrary,PublishTypeLibDesc
• MethodGetClrType (Support clr.GetClrType() - as in IronPython #433)
• MethodGetPythonType (takes a .NETType object and returns the corresponding wrapped Python type)
• MethodGetDynamicType (obsoleted, same asGetPythonType)
• TypesReference andStrongBox (Failure in function selection according to parameters #226)
• Decoratoraccepts (checks the argument types supplied to the decorated function, should be implementable in pure Python)
• Decoratorreturns (validates the result type of a function, also easy in Python)
• MethodSelf (always returnsnull?!)
• MethodsDir andDirClr (can both be mapped todir in our case, I guess)
• MethodConvert (tries to convert the object to the passed type by casting explicitlyevent.Control as foo in ironpython #611 )
• MethodsCompile{Modules,SubclassTypes} (not applicable in our case)
• MethodGetSubclassedTypes (returns a tuple of all types that have been subclassed, does not make sense in CPython)

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