IronPython-0.6 is now available!

[Neuruss]

In any case, it is standard to do time-consuming numerical computation in

Python with the quasi-standard numerical extensions. Unless and until the
these are ported to .NET, such programs will not run. Even when they do,
there is no reason to think that they will be significantly faster.

Well, I don't want to play the advocate of .NET, but I think that we
have to take it with a very practical and pragmatic attitude.
Today, if you want to code something very computational intensive, you
have to resort to C for creating an extension.
Many programers can do it. I can't, because I don't know C and really,
I'm not interested in it.
However, in a .NET environment, you can code your apps in IronPython
(or whatever its name in the future) and when you need extra
performance, you can code this parts in C#. Believe me, I'm just a
newbie, but I can say that translating from Python to C# (if you
already have the python prototype) is a matter of minutes. No
extensions, no hassle...everything compatible and smooth.
Sounds good, don't you think?

 

[John Hunter]

Terry> In any case, it is standard to do time-consuming numerical
Terry> computation in Python with the quasi-standard numerical
Terry> extensions. Unless and until the these are ported to .NET,
Terry> such programs will not run. Even when they do, there is no
Terry> reason to think that they will be significantly faster.

As someone with *no* experience with .NET but with some python
extension code I may one day find myself trying to port to IronPython,
I wonder: does anyone have an idea of what is involved in porting a
python extension module to IronPython / .NET. Any thoughts on how the
use of extension building code interacts with this, eg boost:ython,
pycxx or SWIG?

Thanks, John Hunter

 

[Duncan Booth]

As someone with *no* experience with .NET but with some python
extension code I may one day find myself trying to port to IronPython,
I wonder: does anyone have an idea of what is involved in porting a
python extension module to IronPython / .NET. Any thoughts on how the
use of extension building code interacts with this, eg boost:ython,
pycxx or SWIG?

I think you will find that it will be pretty much a case of rewriting from
scratch. Your extension module will need to be a .NET assembly and this
means writing managed code so you can pretty well forget about any existing
libraries. IronPython isn't likely to be supporting anything close to the
Python C Api.

If you really have to use an existing library then you can maybe write a
wrapper to make it generally usable in .NET. Once your library is usable in
..NET it should become usable by IronPython simply by importing it (assuming
of course that we are talking of some future, more stable version of
IronPython).

 

[Dieter Maurer]

...
Really MI
causes more issues and confusion than it solves.

I recently implemented a core SGML/XML based content management
system within about 4 months.

It heavily uses mixin classes: PropertyManagement, History, WorkflowSupport,
Persistency, Skinnability, DOMSupport, Publishablity, Versionability, ...

Whenever a class needs some elementary feature, it simply inherits
the corresponding mixin class and (maybe) customizes (overrides)
some adapter methods.

Multiple inheritance is vital for this approach!


While it would (of course) be possible to implement such
a system with single inheritance (or even without inheritance),
I guess that the code size would be about 6 times as large
and it would have taken about twice as long:

A class that now just adds a mixin class to its inheritance
list would get littered with redefinitions
for the mixin class's public API functions.

Each redefinition would stupidly delegate to an embedded
instance of the mixin class, thus it is not difficult.
Nevertheless, it would clutter the code, make unnessary effort,
add potential for trivial bugs.


Dieter

 

[Peter Otten]

performance, you can code this parts in C#. Believe me, I'm just a
newbie, but I can say that translating from Python to C# (if you
already have the python prototype) is a matter of minutes. No
extensions, no hassle...everything compatible and smooth.

I that were true, no translation should be needed and no benefits of such a
translation be expected.

But then I'm just a skeptic, don't believe me. Try it.

Peter

 

[Neuruss]

I that were true, no translation should be needed and no benefits of such a
translation be expected.

But then I'm just a skeptic, don't believe me. Try it.

Peter

Even though IronPython will be fully compatible with trhe CLR, it will
still be a dynamic language, with the performance penalty that it
represents.
So in cases where speed is critical, you'll be able to replace the
bottlenecks with c# or other static typed .Net compliant language.
However, Jim Hugunin announced that in the future, Ironpython will
have optional static typing, theoretically making it as fast as c#.