We haven't really done any work on generalizing class creation in the DLR yet. This would correspond to IronPython's NewTypeMaker class which stil lives in Microsoft.Scripting.Vestigial (which is basically things which haven't been fully DLR-ized yet). We also haven't yet added support for adding attributed methods in IronPython either. So that's basically a no for multiple reasons.

We also don't have any continuation support. We could possilby do this for sequences which consisted of only script code but we'd need CLR support to do anything more complex.

If you were to grab an arbitrary mutable object from IronPython you could mutate it and add arbitrary objects to it from another language. There's questions about what are 1st class objects in other languages that I don't know deep enough. But given a fictional language that has 1st class functions you could assign that onto a Python object. How that object gets called will be interesting (Python doesn't implicitly flow this, whereas the calling language may. Therefore you'll get the calling languages behavior)... I think this might be one of the things Jim will blog about soon.

Thanks for the comments Dino :) you must be having a lot of fun at the moment!

Attributes are understandably tricky - I guess I'm just interested in the interoperability story in the short and long term... at this point we cant really write everything we currently do with say C# in a dynamic language like IronPython ... will the DLR move towards reducing the gap over time, so that existing technologies like WCF are easier to work with from dynamic languages, and how soon could this be expected?

Also with regards to things like Continuations (Which to be honest don't really matter to most of us morts :) - is there a time line for getting support in the CLR to nurture these kinds of dynamic language friendly features?

Getting the calling languages behavior makes sense... but I wonder if that might cause problems when interoperability (i.e. consuming a ruby library from python, where say a factory used to create the ruby object is actually changing the functions on a per-instance basis, but from python we end up falling through to a default missing method function). Opposite might be true for say the way IronPython handles multiple inheritance vs another dynamic language like VBScript.

I'll keep any eye on Jim's blog... Are you going to start blogging again yourself Dino?