Oh I understand that. When they got the Dynamic Language Runtime down, they opened up the gates for that. That being said, Python.NET choked up on that test too. I don't think it's using the DLR though.
Really I only give it as something of a final acceptance test for being able to work between one language and Python. And this isn't to nag on Boost and C++ because I can satisfy that criteria with it; it just takes a lot of diplomacy with the GIL. Actually, the more I think of the GIL as being a mutex that I could use Boost's lock structures on, the more fond of the idea I get. Having a recursive lock would have solved a lot of problems, or at least it would have moved me on to the next ones. ;) Anyways professionally I'm stuck with Python.NET because some folks still have some native code they wanted to use. That takes IronPython out of active consideration. Unfortunately I could never find out what all the native stuff was they insisted on keeping. In some cases I've been able to circumvent the callback issue by using events. Those work fine for some reason. On Thu, Dec 27, 2012 at 3:20 PM, Niall Douglas <s_sourcefo...@nedprod.com>wrote: > > Thing is, .NET has a full IDL interop with COM shim and a well > specified threading model. In other words, it provides lots of > support for mixing up lots of different languages, so getting > multiple language interop working on .NET (or even COM) is vastly > easier than anywhere else. > > Niall > >
_______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
