Who is using Python for .NET?
Pardon if this is a loaded question for a beta project. My intent is to speed adoption and interest, not to bust chops. Who is using Python for .NET? Who's kicking its tires? How do you know that it works in various scenarios? What level of application complexity has it been proven to work with? What kinds of scenarios would you expect Python for .NET to be able to handle today, and what scenarios would make you scared? I understand that docs aren't in place yet, so it might be a bit much to ask for a webpage of projects using / evaluating Python for .NET. But, it would probably get more testing and adoption if people were seen to be kicking its tires. If nothing else, I hope this query gets responses. At present the mail archive is quite modest in size, which doesn't indicate a lot of usage unless it's all silent, skilled, highly productive lurking. Any guess on how far out the 1.0 release is? -- Cheers, www.indiegamedesign.com Brandon Van Every Seattle, WA Taking risk where others will not.
Who is using Python for .NET? Who's kicking its tires? How do you know that it works in various scenarios? What level of application complexity has it been proven to work with? What kinds of scenarios would you expect Python for .NET to be able to handle today, and what scenarios would make you scared?
From a view-of-the-guts level, it should able to handle today:
- Simple and intermediate application scripting scenarios (driving objects provided by the application or the framework via scripts) - Prototyping of cmd line and gui apps - Fast unit test development for managed apps What would make me scared: - Complex multithreaded scenarios (the Python integration layer isn't yet well tested in this regard) - Complex COM interop (also mostly for threading concerns) - 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). - Win64 deployment (I know of a few issues that need to be addressed to support 64-bit properly)
I understand that docs aren't in place yet, so it might be a bit much to ask for a webpage of projects using / evaluating Python for .NET. But, it would probably get more testing and adoption if people were seen to be kicking its tires. If nothing else, I hope this query gets responses. At present the mail archive is quite modest in size, which doesn't indicate a lot of usage unless it's all silent, skilled, highly productive lurking.
Any guess on how far out the 1.0 release is?
I've recently had a new addition to the family, so that's put a bit of a crimp in the plan :^) I've really been hoping for more feedback to help figure out how far away 1.0 is. The main things IMHO that I'd like to see happen for 1.0 are: - better tests for threading scenarios - finish and document the embedding apis - basic docs & better packaging - (nice to have) ability to implement abstract managed classes and interfaces in Python Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
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
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.
That should work fine. The bridge is not particularly slow, though it is slower than IL, of course. Method invokation currently happens through reflection, so speed of method calling should be roughly the speed you'd get calling your apis through reflection with C# + some fairly minor overhead for Python <-> managed arg conversion. I have some sneaky ideas on how to make Python <-> managed calls faster and avoid reflection altogether, but I haven't had time to test my theory yet :) Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
participants (2)
-
Brandon J. Van Every
-
Brian Lloyd