[IronPython] Need Help To Start Learning.
adDoc's networker Phil
dr.addn at gmail.com
Mon Oct 17 15:17:00 CEST 2005
. the quick answer for getting started with ironpython
is to get started with zope`s python for .NET
. 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; [@]
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
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 [@]
. not only is pypy getting european funding for being fork-friendly (it`s
written in python),
it also has a back end for llvm [@]
(it compiles python to LLVM (Low-Level Virtual Machine code))
. LLVM is [/]hot:
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
"(. 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
(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).
**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
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.
- 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.
- 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
- 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
- document loading specific versions of assemblies
llvm tip (Execution Engine-independent JIT compilers)
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
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 <http://blogs.msdn.com/brada/archive/2005/01/12/351958.aspx> 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 <http://www.inf.ethz.ch/> 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<http://www.ps.uni-sb.de/%7Ebruni>who worked on the SEAM VM
(see below) and now is in the CLR team.
LIL is described at length in the VM'04
The MPOOL'03 paper
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 <http://www.cierniak.org/research/publications>.
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
Here are references to the related work mentioned in the slides:
- Bartok is a compiler developed by the Advanced Compiler
- 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
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
posted Wednesday, February 23, 2005 4:55
michaljc <http://blogs.msdn.com/Profile.aspx?UserID=3080> with 3
On 10/13/05, Rajesh Sathyamoorthy <rajesh1986 at gmail.com> wrote:
> 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
> users at lists.ironpython.com
American Dream Documents
"(real opportunity starts with real documentation)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ironpython-users