On 10/15/07 Giles Thomas wrote: > Curt Hagenlocher wrote: > > My two cents would be this: using Managed C++, try for source > compatibility first.
As python extensions use a C API, I don't see how Managed C++ would provide source compatibility. Managed C++ would be an ill-advided method, IMHO. > Binary compatibility would be a great thing in the long term - after > all, we don't want to run the risk of branching the target library's > codebase! - but my gut feeling is that you're right, Curt: it would be > much easier, at least as an exploratory first stage, to target source > compatibility only. So perhaps we should start off in that direction. I agree you should aim for source compatibility first, it's not like people commonly use binary proprietary python modules (and if they do it's the same people that wrote them and so can recompile). Binary compatibility is harder to prove correct, anyway and you'll have already your share of issues to overcome:) > Does anyone know how this would impact the potential for Mono compatibility? A Managed C++ implementation would be pretty useless for a mono port, but I think it would be pretty useless for the .net runtime, as you need to expose a C API anyway. You'd have two components: the C API headers and some C code (this is required in any case) is the first. Then you need an assembly that translates from the C API to the IronPython model. You can write this in nice C# + a few dllimports or with the ugly managed C++ (assuming managed C++ can actually consume the python headers). lupus -- ----------------------------------------------------------------- [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better _______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
