Mailman 3 December 2003 - Python.NET

Using an existing Python installation
by Mike Casaday 26 Feb '04

26 Feb '04

Python for .NET is really cool! Here's something I found out while trying to get it to work with my existing Python 2.3 installation. The README says: > **Can I use it with my existing Python installation?** > > Yes, at least on win32 systems. Just copy the files > Python.Runtime.dll and CLR.dll from the PythonNet directory to the > root directory of your python installation. > This answer comes with one caveat in my experience. For some reason you have to 'import CLR' before trying to import anything else from the .NET runtime. This isn't the case if I use the Python executable included in PythonNet-1.0-beta1.tgz, only if I use my existing Python installation. So this fails: from CLR.System.Reflection import Assembly Assembly.LoadWithPartialName('SomeNamespace') import CLR.SomeNamespace as SomeNamespace But this works: import CLR from CLR.System.Reflection import Assembly Assembly.LoadWithPartialName('SomeNamespace') import CLR.SomeNamespace as SomeNamespace Is it possible I'm doing something wrong (more than likely)? Is this a bug? Is this expected behavior? ZODB requires you to 'import ZODB' before you do certain things, so I wouldn't be surprised... ______________ mike P.S. I'm now playing around with the TrueVision3D game engine using Python, something that I couldn't really do until now. I'm happy I saw a link to this project from Daily Python-URL.

3 2

RE: [Python.NET] Who is using Python for .NET?
by Keith J. Farmer 21 Dec '03

21 Dec '03

In the simplest model, SWIG just writes the stub to allow [Python, etc] to use a package written in C++. In any more complicated model, you'd have to ask someone who actually got it to work. There's also a Python package out there that provides access to arbitrary DLLs, as well as the Python Imaging Library, PIL (http://www.pythonware.com/products/pil/). -----Original Message----- From: Brandon J. Van Every [mailto:vanevery@indiegamedesign.com] Sent: Fri 12/19/2003 3:14 AM Martin Kretschmar wrote: > Did you ever have a look at SWIG (http://www.swig.org)?: I didn't. Everything I read in the Python archives said Boost had far better C++ support. I never did ask anyone about it though. Does SWIG have any advantages of simplicity over Boost? I want KISS, not complicated wrappers like Boost makes me deal with.

3 2

Who is using Python for .NET?
by Brandon J. Van Every 19 Dec '03

19 Dec '03

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.

2 3

RE: [Python.NET] Who is using Python for .NET?
by Brandon J. Van Every 19 Dec '03

19 Dec '03

From: Victor A. Wagner, Jr. [mailto:vawjr@rudbek.com] > > It's my personal > belief that Microsoft _still_ intends to bury C++ because they don't > control it. Why can't they want to bury it because it's a fundamentally unproductive enterprise language? Certainly, that's how I feel about it. Why do you think I'm jumping ship to Python? Anyways, I think Microsoft might have been interested in any higher level garbage collected language, "in principle." But Java was Sun's bid to dethrone Microsoft, so of course they couldn't swallow *that* ! So what they decided upon was the (correct) idea of a higher level garbage collected language, but something they own. Witness C# and .NET. And, because these things were created later than Java, some improvements were made over Java. The main one being, not tying your hands "in the Java way" about what your environment is. Interop is basically a better idea than Java's "one platform everywhere" idea. Of course, when one takes a deep look at .NET, it's all plenty interop as long as your problems look like C#! I hope that changes some as .NET evolves. A real proof of pudding will be if we ever get fully viable Python .NET speaking some future version of IL. Then we'll know the Microsoft R&D guys were serious and prevailed in the internal power struggles. > One distinct advantage boost has > over the current PythonNet implementation is that you can go > "either way" with boost. Yes, but at the cost of thinking about everything as C++. I'm moving to Python for the simplicity. Hence, bridging through Managed C++ sounds a lot better to me. I don't believe I need a 2-way bridge for what I'm trying to do, hope I'm not mistaken. A friend of mine also pointed out that I could wrap a few parts of my C++ classes in C, then use the Python/C API. Depends on what I need to expose. It might work in my case, I need some low-level bitmap routines exposed. I don't need Python to do any of the heavy lifting, just to trigger stuff. Cheers, www.indiegamedesign.com Brandon Van Every Seattle, WA 20% of the world is real. 80% is gobbledygook we make up inside our own heads.

2 2

Subtyping in 'C'
by Mark English 18 Dec '03

18 Dec '03

Hope someone can help because I'm stumped. I'm trying to use the new subtyping mechanism. There is a hierarchy of 3 types: Base - The base type C - Type derived from Base D - Type derived from C Base and C both have tp_new functions of their own. Since D doesn't define one, it ends up with C's. (I actually initialise it this way, but I believe that is what "PyType_Ready()" would do anyway) i.e. Base -> tp_new = Base::New C -> tp_new = C::New D -> tp_new = C::New tp_new has the following signature: PyObject * New (PyTypeObject *ptype, PyObject *args, PyObject *kwds) I've tried to follow the existing code and PEP 0253. Base::New calls ptype->tp_alloc and then does some non-varying data initialisation. C::New calls: "ptype->tp_base->tp_new(ptype, args, kwds)" and then does some non-varying data initialisation of its own. As stated, D doesn't have a tp_new function, so it ends up with C's. When constructing an instance of type "D", the following happens: C::New is called, where ptype=D. This delegates to ptype->tp_base->tp_new, where ptype->tp_base is C. C::New is called, where ptype=D. This carries on in a loop. The obvious solution is to pass ptype->tp_base as the ptype parameter in C::New like this: "ptype->tp_base->tp_new(ptype->tp_base, args, kwds)" The problem here is that when the tp_alloc function is called, "ptype" points to the basemost class of the class instance we're actually trying to initialise (in this case "Base"), and so not enough memory will be allocated. So currently the choice lies between blowing up the stack in an infinite loop, or initialising too small an amount of memory. Could get the functions to call the base type functions explicitly, without going through the tp_new pointer, but that seems kinda dirty. Thinking about hacking the object size in the "Base" type temporarily, so that at least I can allocate the correct amount of memory. Also not pretty but leaves the indirection alone. I'm using ActivePython 2.2.2 and I'd really rather not upgrade or switch yet. Any help, gratefully received. Cheers, mE ----------------------------------------------------------------------- The information contained in this e-mail is confidential and solely for the intended addressee(s). Unauthorised reproduction, disclosure, modification, and/or distribution of this email may be unlawful. If you have received this email in error, please notify the sender immediately and delete it from your system. The views expressed in this message do not necessarily reflect those of LIFFE Holdings Plc or any of its subsidiary companies. -----------------------------------------------------------------------

1 0

RE: [Python.NET] Who is using Python for .NET?
by Keith J. Farmer 18 Dec '03

18 Dec '03

Is Managed DirectX an option? Have you looked into other Python/.NET implementations? (ie, IronPython, not yet released, is showing promise -- search google) Another route is via COM: write COM classes in .NET, and instantiate in Python. I haven't tried it, but I believe it's possible. -----Original Message----- From: Brandon J. Van Every [mailto:vanevery@indiegamedesign.com] Sent: Wed 12/17/2003 11:37 AM 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.

2 1

RV: [Python.NET] Who is using Python for .NET?
by Eduardo Gironas 17 Dec '03

17 Dec '03

You have the next note: "Taking risk where others will not." May be, many members of this SIG have it in mind. I personally like Python, it is one of the most natural languajes I ever seen. I do simulations and very fast and ad-hoc works with it (not in .net environment by the moment). With time I accumulated many objects that I re-use (for reading files, formatting, reports, formulas, etc). So, a great expectations exists for people who loves Python when there the possiblitiy to integrate this to .net world. I think this languaje needs to survive, I think it is necessary to follow the shark and make heroic attempts (i.e python for .net). Of course, not all people likes python, and it depends of every one of us to go ahead and take the risk. One never knows what is behind the door. -----Mensaje original----- De: pythondotnet-bounces(a)python.org [mailto:pythondotnet-bounces@python.org]En nombre de Brandon J. Van Every Enviado el: Martes, 16 de Diciembre de 2003 05:23 a.m. Para: Python.NET Asunto: [Python.NET] 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. _________________________________________________ Python.NET mailing list - PythonDotNet(a)python.org http://mail.python.org/mailman/listinfo/pythondotnet

1 0

RE: [Python.NET] IronPython
by Keith J. Farmer 14 Dec '03

14 Dec '03

> From: Jim Hugunin [mailto:jim@hugunin.net] > Subject: RE: IronPython question > > IronPython works as both an interpreter and compiler. In its current form > it generates a separate assembly for each Python module. These can be > generated entirely in memory or written to disk. Currently there's no > mode to generate a single assembly for a Python application composed of a > number of modules, but that's a straight-forward extension. > > -Jim I just informed Jim about this list (he didn't know about it). ---------- Keith J. Farmer kfarmer(a)thuban.org http://www.thuban.org -----Original Message----- From: Marek Kubica [mailto:whg_channel@lycos.de] Sent: Thursday, December 11, 2003 10:20 would IronPython work like PythonDotNet by Mark Hammond (compiles Python to IL, so no interpreter needed)?

1 0

RE: [Python.NET] IronPython
by Keith J. Farmer 11 Dec '03

11 Dec '03

I would really like to see a compiled Python. I think that would be very useful, but of course would require certain changes. I would be all for strongly-typed public members (leaving the private stuff to its current, variant-ish behavior), with the default being for private membership. I think the CLR allows objects to return their actual type even if passed in as object types, no? Otherwise, IronPython seems to be the next best thing, and rather exciting. I wonder if he's using the CodeDom to do eval()? I think it would be relatively decent way to go about things. Of course, he could wrap that part of the CPython interpreter... -----Original Message----- From: Christian Wilcox [mailto:cawilcox@charter.net] Sent: Wed 12/10/2003 4:44 PM Check out http://primates.ximian.com/~miguel/ironpython.

2 1

IronPython
by Christian Wilcox 11 Dec '03

11 Dec '03

Check out http://primates.ximian.com/~miguel/ironpython. Here's a snippet from the post referenced by the link (the author is Jim Hugunin, creator of Jython and Numeric Python): <quote> I've been working off and on for the past couple of months on a new implementation of Python for the CLR called IronPython. It compiles Python programs into verifiable IL and then dynamically executes them. This project began as an investigation of the performance issues involved with compiling Python to run as managed code on the CLR. Previous work had indicated that runtime performance could be prohibitively slow [1]. The early results with IronPython show that Python compiled to IL can run fast. On the standard pystone benchmark, IronPython-0.1 is 70% faster than CPython-2.3. The numbers for pystone as well as several micro-benchmarks are shown below. For ease of comparison, all times are normalized to Python-2.3. Smaller numbers indicate faster performance. IronPython-0.1 Python-2.3 Python-2.1 Jython-2.1 pystone 0.58 1.00 1.29 1.61 function call 0.19 1.00 1.12 1.33 integer add 0.59 1.00 1.18 1.08 string.replace 0.92 1.00 1.00 1.40 range(bigint) 5.57 1.00 1.09 16.02 eval("2+2") 66.97 1.00 1.58 91.33 </quote> Thoughts??? Christian Wilcox

1 0