Mailman 3 February 2004 - Python.NET

RE: Re[2]: [Python.NET] Anyone or anything happening here?
by Hawkeye Parker March 1, 2004

March 1, 2004

http://www.python.org "python" is "cpython" when people talk about jpython or python.net or any other python, they use "cpython" to explicitly refer to THE "original" python. i believe this is because the low level python (cpython) libs and python interpreter are written in C. > -----Original Message----- > From: pythondotnet-bounces(a)python.org > [mailto:pythondotnet-bounces@python.org]On Behalf Of Leonard :paniq: > Ritter > Sent: Friday, February 27, 2004 1:05 PM > To: PythonDotNet(a)python.org > Subject: Re[2]: [Python.NET] Anyone or anything happening here? > > > > (whoops, sent to individual instead of mailing list first) > > i heard a lot of this mysterious "CPython", could anybody give me a > hint on how to get it and check it out? google doesnt give me useful > resuls. > > would be charming, if it is an x86 compiler for a typed python dialect > :) > > -- Leonard Ritter > -- paniq(a)gmx.net > -- http://www.paniq.de > -- http://www.the-mu.com > > Friday, February 27, 2004, 8:03:25 PM, you wrote: > > > Mcic> Actually, Hawkeye (and the OP) , it's yet a bit more > than that. I agree > Mcic> that "it is not "Python.Net"" (it does not make Python > run as a .NET > Mcic> language), but it does allow you to embed Python in a > .NET app. In fact, as > Mcic> you're probably aware, the python.exe that you run when > using Python for > Mcic> .NET in the conventional way (see documented examples) > is a simple example > Mcic> of embedding Python in a (very small) .NET app, which > in turn provides > Mcic> access to a very rich interface for calling back in the > other direction. > > Mcic> The viewpoint one has while using Python for .NET in > the conventional way > Mcic> (running the CLR-enabled python.exe, importing CLR, and > going from there) > Mcic> is that the CLR is acting as an appendage to Python. > But in fact there is a > Mcic> duality in this architecture that is subtle but > amazingly flexible. You > Mcic> might say that in this clever framework, Python and > .NET are mutually > Mcic> embedded, which offers some unique possibilities > similar to, but even more > Mcic> powerful than, Jython. > > Mcic> BTW, Jython is pretty cool too, but I prefer Python for > .NET because it is > Mcic> real CPython, so almost anything that you could do in > Python before > Mcic> integrating it with .NET, you can still do. In Jython, > any python code has > Mcic> to be available in source form so it can be compiled by > Jython (at least > Mcic> once) whereasany Python byte code that works with the > currently supported > Mcic> Python runtime (2.3 currently) will work with Python for .NET. > > Mcic> The somewhat downplayed embedding capability is the > aspect of Python for > Mcic> .NET that I am personally finding very useful, with the > "calling back to > Mcic> .NET" feature being a very nice bonus, allowing the > embedding .NET app to > Mcic> use Python to allow it to sort-of "script into itself". > > > Mcic> P.S. -- I am not contradicting you (your answer to the > OP is completely > Mcic> correct) -- I'm just adding a viewpoint that I have > found useful. > > Mcic> ========================== > Mcic> Mark Barclay > Mcic> Sr. Software Engineer, CRi Inc. > > > > Mcic> |---------+-------------------------------> > Mcic> | | "Hawkeye Parker" | > Mcic> | | <hawkeye.parker@auto| > Mcic> | | desk.com> | > Mcic> | | Sent by: | > Mcic> | | pythondotnet-bounces| > Mcic> | | @python.org | > Mcic> | | | > Mcic> | | | > Mcic> | | 02/27/2004 01:05 PM | > Mcic> | | | > Mcic> |---------+-------------------------------> > Mcic> > Mcic> > >------------------------------------------------------------- > ------------------------------------------------------| > Mcic> | > Mcic> | To: <srussell(a)lotmate.com>, > Mcic> <pythondotnet(a)python.org> > Mcic> | cc: > Mcic> | Subject: RE: [Python.NET] Anyone or anything > Mcic> happening here? | > Mcic> > Mcic> > >------------------------------------------------------------- > ------------------------------------------------------| > > > > > Mcic> http://www.zope.org/Members/Brian/PythonNet/index_html > > Mcic> AFAIK, this is the only fully working (beta) > implementation of anything > Python >> .Net. take a look at the link contents for details on this > Mcic> implementation. basically, it allows CPython access to > .Net, but not the > Mcic> other way around. it is not "Python.Net", but CPython > *for* .Net . . . . > Mcic> IMHO, it's quite good, and others on the list seem to > like what it does/how > Mcic> it works. > > > > > > > Mcic> _________________________________________________ > Mcic> Python.NET mailing list - PythonDotNet(a)python.org > Mcic> http://mail.python.org/mailman/listinfo/pythondotnet > > > > _________________________________________________ > Python.NET mailing list - PythonDotNet(a)python.org > http://mail.python.org/mailman/listinfo/pythondotnet >

3 2

Re[2]: [Python.NET] Anyone or anything happening here?
by Leonard :paniq: Ritter Feb. 27, 2004

Feb. 27, 2004

(whoops, sent to individual instead of mailing list first) i heard a lot of this mysterious "CPython", could anybody give me a hint on how to get it and check it out? google doesnt give me useful resuls. would be charming, if it is an x86 compiler for a typed python dialect :) -- Leonard Ritter -- paniq(a)gmx.net -- http://www.paniq.de -- http://www.the-mu.com Friday, February 27, 2004, 8:03:25 PM, you wrote: Mcic> Actually, Hawkeye (and the OP) , it's yet a bit more than that. I agree Mcic> that "it is not "Python.Net"" (it does not make Python run as a .NET Mcic> language), but it does allow you to embed Python in a .NET app. In fact, as Mcic> you're probably aware, the python.exe that you run when using Python for Mcic> .NET in the conventional way (see documented examples) is a simple example Mcic> of embedding Python in a (very small) .NET app, which in turn provides Mcic> access to a very rich interface for calling back in the other direction. Mcic> The viewpoint one has while using Python for .NET in the conventional way Mcic> (running the CLR-enabled python.exe, importing CLR, and going from there) Mcic> is that the CLR is acting as an appendage to Python. But in fact there is a Mcic> duality in this architecture that is subtle but amazingly flexible. You Mcic> might say that in this clever framework, Python and .NET are mutually Mcic> embedded, which offers some unique possibilities similar to, but even more Mcic> powerful than, Jython. Mcic> BTW, Jython is pretty cool too, but I prefer Python for .NET because it is Mcic> real CPython, so almost anything that you could do in Python before Mcic> integrating it with .NET, you can still do. In Jython, any python code has Mcic> to be available in source form so it can be compiled by Jython (at least Mcic> once) whereasany Python byte code that works with the currently supported Mcic> Python runtime (2.3 currently) will work with Python for .NET. Mcic> The somewhat downplayed embedding capability is the aspect of Python for Mcic> .NET that I am personally finding very useful, with the "calling back to Mcic> .NET" feature being a very nice bonus, allowing the embedding .NET app to Mcic> use Python to allow it to sort-of "script into itself". Mcic> P.S. -- I am not contradicting you (your answer to the OP is completely Mcic> correct) -- I'm just adding a viewpoint that I have found useful. Mcic> ========================== Mcic> Mark Barclay Mcic> Sr. Software Engineer, CRi Inc. Mcic> |---------+-------------------------------> Mcic> | | "Hawkeye Parker" | Mcic> | | <hawkeye.parker@auto| Mcic> | | desk.com> | Mcic> | | Sent by: | Mcic> | | pythondotnet-bounces| Mcic> | | @python.org | Mcic> | | | Mcic> | | | Mcic> | | 02/27/2004 01:05 PM | Mcic> | | | Mcic> |---------+-------------------------------> Mcic> Mcic> >-------------------------------------------------------------------------------------------------------------------| Mcic> | Mcic> | To: <srussell(a)lotmate.com>, Mcic> <pythondotnet(a)python.org> Mcic> | cc: Mcic> | Subject: RE: [Python.NET] Anyone or anything Mcic> happening here? | Mcic> Mcic> >-------------------------------------------------------------------------------------------------------------------| Mcic> http://www.zope.org/Members/Brian/PythonNet/index_html Mcic> AFAIK, this is the only fully working (beta) implementation of anything Python >> .Net. take a look at the link contents for details on this Mcic> implementation. basically, it allows CPython access to .Net, but not the Mcic> other way around. it is not "Python.Net", but CPython *for* .Net . . . . Mcic> IMHO, it's quite good, and others on the list seem to like what it does/how Mcic> it works. Mcic> _________________________________________________ Mcic> Python.NET mailing list - PythonDotNet(a)python.org Mcic> http://mail.python.org/mailman/listinfo/pythondotnet

1 0

RE: [Python.NET] Anyone or anything happening here?
by Hawkeye Parker Feb. 27, 2004

Feb. 27, 2004

i agree %100, and your explanation does true justice to this excellent framework. thanks for taking the time, hawkeye > -----Original Message----- > From: MBarclay(a)cri-inc.com [mailto:MBarclay@cri-inc.com] > Sent: Friday, February 27, 2004 11:03 AM > To: Hawkeye Parker > Cc: pythondotnet(a)python.org; pythondotnet-bounces(a)python.org; > srussell(a)lotmate.com > Subject: RE: [Python.NET] Anyone or anything happening here? > > > > Actually, Hawkeye (and the OP) , it's yet a bit more than > that. I agree > that "it is not "Python.Net"" (it does not make Python run as a .NET > language), but it does allow you to embed Python in a .NET > app. In fact, as > you're probably aware, the python.exe that you run when using > Python for > .NET in the conventional way (see documented examples) is a > simple example > of embedding Python in a (very small) .NET app, which in turn provides > access to a very rich interface for calling back in the other > direction. > > The viewpoint one has while using Python for .NET in the > conventional way > (running the CLR-enabled python.exe, importing CLR, and going > from there) > is that the CLR is acting as an appendage to Python. But in > fact there is a > duality in this architecture that is subtle but amazingly > flexible. You > might say that in this clever framework, Python and .NET are mutually > embedded, which offers some unique possibilities similar to, > but even more > powerful than, Jython. > > BTW, Jython is pretty cool too, but I prefer Python for .NET > because it is > real CPython, so almost anything that you could do in Python before > integrating it with .NET, you can still do. In Jython, any > python code has > to be available in source form so it can be compiled by > Jython (at least > once) whereasany Python byte code that works with the > currently supported > Python runtime (2.3 currently) will work with Python for .NET. > > The somewhat downplayed embedding capability is the aspect of > Python for > .NET that I am personally finding very useful, with the > "calling back to > .NET" feature being a very nice bonus, allowing the embedding > .NET app to > use Python to allow it to sort-of "script into itself". > > > P.S. -- I am not contradicting you (your answer to the OP is > completely > correct) -- I'm just adding a viewpoint that I have found useful. > > ========================== > Mark Barclay > Sr. Software Engineer, CRi Inc. > > > > |---------+-------------------------------> > | | "Hawkeye Parker" | > | | <hawkeye.parker@auto| > | | desk.com> | > | | Sent by: | > | | pythondotnet-bounces| > | | @python.org | > | | | > | | | > | | 02/27/2004 01:05 PM | > | | | > |---------+-------------------------------> > > >------------------------------------------------------------- > ------------------------------------------------------| > | > | > | To: <srussell(a)lotmate.com>, > <pythondotnet(a)python.org> > | > | cc: > | > | Subject: RE: [Python.NET] Anyone or anything > happening here? | > > >------------------------------------------------------------- > ------------------------------------------------------| > > > > > http://www.zope.org/Members/Brian/PythonNet/index_html > > AFAIK, this is the only fully working (beta) implementation > of anything > Python > .Net. take a look at the link contents for details on this > implementation. basically, it allows CPython access to .Net, > but not the > other way around. it is not "Python.Net", but CPython *for* > .Net . . . . > IMHO, it's quite good, and others on the list seem to like > what it does/how > it works. > > > > > >

1 0

RE: [Python.NET] Anyone or anything happening here?
by MBarclay＠cri-inc.com Feb. 27, 2004

Feb. 27, 2004

Actually, Hawkeye (and the OP) , it's yet a bit more than that. I agree that "it is not "Python.Net"" (it does not make Python run as a .NET language), but it does allow you to embed Python in a .NET app. In fact, as you're probably aware, the python.exe that you run when using Python for .NET in the conventional way (see documented examples) is a simple example of embedding Python in a (very small) .NET app, which in turn provides access to a very rich interface for calling back in the other direction. The viewpoint one has while using Python for .NET in the conventional way (running the CLR-enabled python.exe, importing CLR, and going from there) is that the CLR is acting as an appendage to Python. But in fact there is a duality in this architecture that is subtle but amazingly flexible. You might say that in this clever framework, Python and .NET are mutually embedded, which offers some unique possibilities similar to, but even more powerful than, Jython. BTW, Jython is pretty cool too, but I prefer Python for .NET because it is real CPython, so almost anything that you could do in Python before integrating it with .NET, you can still do. In Jython, any python code has to be available in source form so it can be compiled by Jython (at least once) whereasany Python byte code that works with the currently supported Python runtime (2.3 currently) will work with Python for .NET. The somewhat downplayed embedding capability is the aspect of Python for .NET that I am personally finding very useful, with the "calling back to .NET" feature being a very nice bonus, allowing the embedding .NET app to use Python to allow it to sort-of "script into itself". P.S. -- I am not contradicting you (your answer to the OP is completely correct) -- I'm just adding a viewpoint that I have found useful. ========================== Mark Barclay Sr. Software Engineer, CRi Inc. |---------+-------------------------------> | | "Hawkeye Parker" | | | <hawkeye.parker@auto| | | desk.com> | | | Sent by: | | | pythondotnet-bounces| | | @python.org | | | | | | | | | 02/27/2004 01:05 PM | | | | |---------+-------------------------------> >-------------------------------------------------------------------------------------------------------------------| | | | To: <srussell(a)lotmate.com>, <pythondotnet(a)python.org> | | cc: | | Subject: RE: [Python.NET] Anyone or anything happening here? | >-------------------------------------------------------------------------------------------------------------------| http://www.zope.org/Members/Brian/PythonNet/index_html AFAIK, this is the only fully working (beta) implementation of anything Python > .Net. take a look at the link contents for details on this implementation. basically, it allows CPython access to .Net, but not the other way around. it is not "Python.Net", but CPython *for* .Net . . . . IMHO, it's quite good, and others on the list seem to like what it does/how it works.

1 0

RE: [Python.NET] Anyone or anything happening here?
by Hawkeye Parker Feb. 27, 2004

Feb. 27, 2004

http://www.zope.org/Members/Brian/PythonNet/index_html AFAIK, this is the only fully working (beta) implementation of anything Python > .Net. take a look at the link contents for details on this implementation. basically, it allows CPython access to .Net, but not the other way around. it is not "Python.Net", but CPython *for* .Net . . . . IMHO, it's quite good, and others on the list seem to like what it does/how it works. > -----Original Message----- > From: pythondotnet-bounces(a)python.org > [mailto:pythondotnet-bounces@python.org]On Behalf Of Stephen Russell > Sent: Friday, February 27, 2004 5:58 AM > To: pythondotnet(a)python.org > Subject: [Python.NET] Anyone or anything happening here? > > > I was interested in seeing if Python on .NET was possible? > > Stephen Russell > S.R. & Associates > Memphis TN 38115 > 901.246-0159 > > "Most people hate the taste of beer - to begin with. It is, however, a > prejudice that many people have been able to overcome." > --Winston Churchill > > > _________________________________________________ > Python.NET mailing list - PythonDotNet(a)python.org > http://mail.python.org/mailman/listinfo/pythondotnet >

2 1

Anyone or anything happening here?
by Stephen Russell Feb. 27, 2004

Feb. 27, 2004

I was interested in seeing if Python on .NET was possible? Stephen Russell S.R. & Associates Memphis TN 38115 901.246-0159 "Most people hate the taste of beer - to begin with. It is, however, a prejudice that many people have been able to overcome." --Winston Churchill

1 0

buglet in module importing
by Greg Chapman Feb. 26, 2004

Feb. 26, 2004

I just ran into this using the PythonNet-1.0-beta3 release. If you start interactive Python and do this: >>> import CLR.System.Resources No error is raised. However, the import has in fact failed: >>> from CLR.System.Threading import Thread >>> assemblies = Thread.GetDomain().GetAssemblies() >>> [a.FullName.split(',', 1)[0] for a in assemblies] [u'mscorlib', u'python', u'Python.Runtime', u'e__NativeCall_Assembly', u'System', u'System.Xml']. The System.Resources module is in the System.Windows.Forms assembly, but as you can see, that assembly has not been loaded. I believe the problem is that the above import statement ultimately ends up in a call to Assembly.LoadWithPartialName("System.Resources"). This fails because there is no such assembly. For some reason, this failure does not seem to be raising a Python exception, though I think it should. The workaround is to import System.Windows.Forms before importing System.Resources. --- Greg Chapman

1 0

Using an existing Python installation
by Mike Casaday Feb. 25, 2004

Feb. 25, 2004

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] importing Assembly
by Geraint Williams Feb. 25, 2004

Feb. 25, 2004

Hi, thanks for the response but have already solved the problem. The Assembly (which I had copied to the python dir) referenced another assembly (which I had not - although I think I may have been included in my path). Copying the referenced assembly to my python dir did the trick. Anyway, thanks for the product... has made my life (testing a .NET assembly) far easier. Find it far more productive writing test scripts in a scripting language than in C# development environment. Cheers, Geraint. >From: "Brian Lloyd" <brian(a)zope.com> >To: "Geraint Williams" ><gerainthuwwilliams(a)hotmail.com>,<pythondotnet(a)python.org> >Subject: RE: [Python.NET] importing Assembly >Date: Tue, 24 Feb 2004 22:00:53 -0500 > > > I see that this has been asked before, but I must be missing something > > > > >>>import CLR.Company.Product.Module > > Traceback (most recent call last): > > File "<stdin>", line 1, in ? > > ImportError: No module named Company > > > > The dll I have is called: "Company.Product.Module.dll", and is > > copied into > > the python root dir > > > > The source code for the module defines namespace as "namespace > > Company.Product.Module" > > > > Also I try the following: > > > > >>>from CLR.System.Reflection import Assembly > > >>>a = Assembly.LoadWithPartialName('Company.Product.Module') > > >>>import CLR.Company.Product.Module > > Traceback (most recent call last): > > File "<stdin>", line 1, in ? > > ImportError: No module named Company > > > > please excuse any obvious ignorance of .NET terminology, it's > > something I've > > just started looking at. > >Sorry I'm late on this - my spam filter starting eating some >of my mailing list email a week or so ago and I'm still catching >up :( > >I'm curious whether you can use reflection to loop over the types >defined in your assembly after using LoadWithPartialName to load >it. What you are doing looks like it _should_ work fine. > >Brian Lloyd brian(a)zope.com >V.P. Engineering 540.361.1716 >Zope Corporation http://www.zope.com > > _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

1 0

importing Assembly
by Geraint Williams Feb. 25, 2004

Feb. 25, 2004

I see that this has been asked before, but I must be missing something >>>import CLR.Company.Product.Module Traceback (most recent call last): File "<stdin>", line 1, in ? ImportError: No module named Company The dll I have is called: "Company.Product.Module.dll", and is copied into the python root dir The source code for the module defines namespace as "namespace Company.Product.Module" Also I try the following: >>>from CLR.System.Reflection import Assembly >>>a = Assembly.LoadWithPartialName('Company.Product.Module') >>>import CLR.Company.Product.Module Traceback (most recent call last): File "<stdin>", line 1, in ? ImportError: No module named Company please excuse any obvious ignorance of .NET terminology, it's something I've just started looking at. Thanks, Geraint _________________________________________________________________ Tired of 56k? Get a FREE BT Broadband connection http://www.msn.co.uk/specials/btbroadband

2 1