is to get started with zope`s python for .NET
[EMAIL PROTECTED] http://www.zope.org/Members/Brian/PythonNet/readme.html#getting_started
. ironpython is at microsoft and it is alpha;
so, there may not be a lot of help besides knowing that
iron python is just python for another platform (lots of help for python)
. an easier approach might come from zope; [EMAIL PROTECTED] http://www.zope.org/Members/Brian/PythonNet
but, this appears to have a problem with python`s exceptions being old-style classes, instead of new-style classes that don't have to subclass Python's Exception class,
although Py'NET`s author is under the impression that the
next version of Python might change for .NET compatability
. I'm personally putting my bets on pypy [EMAIL PROTECTED] http://codespeak.net/pypy/dist/pypy/doc/index.html
. not only is pypy getting european funding for being fork-friendly (it`s written in python),
it also has a back end for llvm [EMAIL PROTECTED] http://lambda-the-ultimate.org/node/view/141#comment-986
(it compiles python to LLVM (Low-Level Virtual Machine code))
. LLVM is [/]hot:
[EMAIL PROTECTED] http://llvm.cs.uiuc.edu/
every language should have a port to LLVM;
and every platform should have an LLVM -to- native|managed code compiler
Python for .NET 1.0 beta 5 is based on Python 2.4
[EMAIL PROTECTED] http://www.zope.org/Members/Brian/PythonNet/Releases/PythonNet-1.0-beta5.tgz
"(. zope`s package does not produce managed code (IL) from Python code
. Rather, it is
an integration of the C Python engine with the .NET runtime
. This
approach allows you to use the CLR services
and continue to use existing
Python C extensions
while maintaining native execution speeds for Python
code. )
Why Python For .NET?
Python for .NET gives Python programmers near-seamless integration
with
the .NET Common Language Runtime (CLR)
and provides a powerful tool for
application scripting for .NET developers
. Using this package you can
script CLR applications
or build entire applications in Python,
using
CLR services and components written in any language that targets the
CLR
(Managed C++, C#, VB, JScript, etc.).
Is This Like Jython for .NET?
Not really. Jython provides an implementation of the Python language and runtime engine in pure Java. Python for .NET is not a re-implementation of Python, just an integration of the existing CPython runtime with .NET.
While a solution like Jython provides "two-way" interoperability, this package only provides "one-way" integration. Meaning, while Python can use types and services implemented in .NET, managed code cannot generally use classes implemented in Python.
A Jython-like solution for .NET would certainly be doable and useful - but it would also require far more work than the current approach.
Is This Related To ActiveState's Python.NET Work?
No. That effort focused on the feasibility of making Python a true .NET language (compiling Python to IL). You can find that work as well as a paper describing the goals and results at http://www.activestate.com.
[*][. this is from the [/]download`s readme:]
open source Zope Public License (ZPL).
: http://www.zope.org/Products/Zope/LICENSE_20.txt.
**Does it work with Mono?**
Preliminary testing shows that PythonNet will run under mono, though the
test suite fails quickly due to NotImplemented errors raised in parts of
the Mono runtime. The PythonNet integration layer is 100% managed code,
so there are no long-term issues under mono - it should work better and
better as the mono platform matures.
It is not currently possible to *build* PythonNet using only the Mono
tools, due to an issue involving the Mono assembler / disassembler. You
should, however, be able to try the pre-built assembly under Mono (or
compile it yourself with the MS tools and run it under Mono).
Note that if you are running under Mono on a *nix system, you will need
to have Python 2.4 installed. You will probably also have to make a
symlink in the PythonNet directory pointing to the libpython2.4.so on
your system. You will need to name the symlink 'python24.so'.
**What is the current status of the package?**
The Python for .NET runtime is quite stable and is nearly feature
complete. There are a large number of unit tests as well as a number
of stress tests, leak tests and demo scripts. There are still
some loose ends to finish up for the 1.0 release, but it is definitely
usable for real applications.
Current issues:
- Managed exceptions are not integrated well with Python exceptions, due
to Python's insistence that exceptions must be old-style classes. Not
sure if there is a sneaky way around it, other than lobbying Guido to
look at it for a future Python version. Currently, it looks like
Python 2.5 will support new-style classes as exceptions.
- Packaging is still pretty minimal. There should probably be an msi
installer etc. for win32.
[*]distr`doc/todo:
ToDo List:
- incorporate fxcop suggestions
- out, ref params
-
- Fix anything that relies on member order in reflection - this will
change post 1.1
- Support out and in/out params
- fix loss of python wrapped instances when handed over to clr
- Finish leaktest.py and finish checking for leaks.
- Implement class wrappers to allow Python code to implement interfaces
and abstract .NET classes
- Finish basic embedding APIs & tests
- Integrate nunit 2
- Test thread state management & async delegates
- Tests for overload selection
- Cached type in TypeManager need to be cleaned up on managed
runtime finalization (low priority); review finalization
generally.
- Pester Guido about letting exceptions be new-style classes that
don't have to subclass Python's Exception class :) See if there is
some sneaky way around it.
- Look at optimizing some type conversions
FAQ items:
- document loading specific versions of assemblies
llvm tip (Execution Engine-independent JIT compilers)
[EMAIL PROTECTED] http://blogs.msdn.com/michaljc/
I have recently put together a set of slides about LIL (Low-level Intermediate Language) and gave a talk at Microsoft. This work was done before I joined Microsoft: LIL was developed by the ORP (Open Runtime Platform) team at Intel. LIL was addressing multiple issues in the ORP design (papers referenced below can give you an idea) but the focus of this presentation was more narrow: how to improve the interface between the JIT (Just-In-Time compiler) and the rest of the VM. I'd like to point out that I use the terms VM (Virtual Machine) and EE (Execution Engine) interchangeably (see this post for a discussion of this terminology). Others have come up independently with somewhat similar ideas and I found quite a lot of interest in the LIL approach in conversations both inside and outside of Microsoft. For my current presentation I took some of the old LIL slides that I used in a talk I gave at ETH Zürich in 2003 and modified them to focus on the JIT/EE interface. This version of slides benefited from my conversations with many people in the last year, after the original LIL papers were published. I think that I owe most to my conversations with George Bosworth and to comments by Thorsten Brunklaus who worked on the SEAM VM (see below) and now is in the CLR team.
LIL is described at length in the VM'04 paper. The MPOOL'03 paper (pdf) presents some thoughts on how LIL could be used to abstract away the object model from the JIT. Full references to these two papers are available on my publications page.
The talk I just gave had the title "Execution Engine-independent JIT compilers" and the basic idea is that LIL enables a much better abstraction of the EE from a JIT's point of view then what is used in all known to me implementations of virtual machines for JVM and CLR/CLI. I made the full presentation available as a pdf file.
Here are references to the related work mentioned in the slides:
- Bartok is a compiler developed by the Advanced Compiler Technology group at MSR
- JikesRVM: http://www.ibm.com/developerworks/oss/jikesrvm
- LLVM: http://llvm.cs.uiuc.edu
- C--: http://www.cminusminus.org
- SEAM: http://www.ps.uni-sb.de/seam (also, this discussion is an entertaining read if you want to see varied opinions on the subject)
- PCR: http://portal.acm.org/citation.cfm?id=74862
- Alan Kay's quote is from the ACM Queue article.
posted Wednesday, February 23, 2005 4:55 PM by michaljc with 3 Comments
Hi,
I am familiar with python but not with .NET. I also do not know any other programming language like C# and VB so following tutorials can be difficult. What steps should I take to start learning how to use ironpython?
Thank You.
_______________________________________________
users mailing list
[email protected]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
--
American Dream Documents
http://www.geocities.com/amerdreamdocs/home/
"(real opportunity starts with real documentation)
_______________________________________________ users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
