From: Brian Lloyd [mailto:brian@zope.com]
What would make me scared:
- Apps with extreme performance requirements (the approach of integrating the C Python runtime brings with it certain drawbacks related to the Python global interpreter lock).
Ok, on this point I'll ask you for further details. I'm writing a game with a lot of 3D graphics and AI code in it. That kind of code always has a high performance requirement somewhere. But in the hands of an architect such as myself, it's not an "in general" requirement, rather there will be specific systems that must be implemented in C++. My plan is to implement the Native C++ code in the .NET way, using Managed C++ as the bridge. Python then talks to .NET to get at the performance stuff. Does this pose any problems? Is the Python .NET bridge excruciatingly slow or anything like that? I will be crossing the bridge frequently. The point is to use Python to glue together some high performance low level routines, and to script various computationally intensive AI behaviors in this way. I'm not going to use Boost. I read the intro tutorial and ran screaming from the room. Boost requires nit-picky C++ implementation effort using weird templates and so forth. The point of me using Python is to not do C++ any more than absolutely necessary for performance, and writing Boost wrappers is actually worse than just writing C++ code. When *I* write C++ code, I can KISS, code defensively, avoid templates, basically avoid all of C++'s common pitfalls. With Boost, I have to use picky template syntax, and know all the potential exceptions and pitfalls of particular circumstances. In a pure C++ project I can worry about all that stuff once and then forget about it. In a Boost-Python bridge, I have to write all that stuff *twice* and I am never allowed to forget it, lest the bridge breaks. It makes modifying anything over the bridge a nightmare, especially in the hands of others that do not know the code as intimately as you do. I'm curious if anyone else has strongly negative feelings about the Boost approach? Is that why anyone else is here trying Python for .NET? I think it would be a major promotional bullet point to say "This is *far* simpler than Boost." Anyone think I'm overstating how bad Boost is? It looks like a C++ guy's wet dream, but I think it would make a Pythonista cross fingers and hiss.
I've recently had a new addition to the family, so that's put a bit of a crimp in the plan :^)
Congratulations! Cheers, Brandon Van Every