Mono and Python
Robert N. Deviasse
rdeviasse at sympatico.ca
Wed Jan 2 21:23:48 EST 2002
"Andrew Kuchling" <akuchlin at mems-exchange.org> wrote in message
news:3dheq44v45.fsf at ute.mems-exchange.org...
> Similarly, I think MS would like people to use the CLI/CLR and
> therefore entices them with the run-any-language-you-like carrot. But
> only C# and VB will run really quickly -- remember, the .net port of
> Python ran about 10 times slower than MS's anointed languages,
That's a poor example. Take a look at their whitepaper:
It basically says:
The Python for .NET compiler is written using CPython.
It compiles Python source code, and uses the .NET Reflection::Emit
library to generate a .NET assembly. The COM Interoperability
features of .NET are used to access the Reflection::Emit library.
This particular strategy was chosen to minimize the implementation
The primary drawback to this approach is the speed of the compiler.
Much of the abstract syntax tree (AST) manipulation code is also
written in Python code, and as this is one of the most CPU intensive
areas of the compiler, we suffer a significant speed penalty.
Further, the use of Reflection::Emit via COM is also causing us some
performance problems. Some of these problems are due to the speed of
the Python COM bindings, but Reflection::Emit itself and/or the COM
interoperability layers are also costing us significant time.
They basically chose the extremely slow approach in order to implement it
quickly. COM itself is slow, but writing a CPU intensive part of the code
Python sure doesn't help performance.
Later on, they say:
The Python for .NET runtime defines a .NET interface (IPyType)
that captures Python's semantics. The definition of this interface
is almost identical to the existing CPython type object, which is
the object primarily responsible for object semantics in CPython.
The Python for .NET runtime also exposes an API for use by the
compiler, working almost exclusively with the PyObject structures.
The runtime also provides a function for creating a new PyObject
at runtime, given nothing but an anonymous .NET object reference.
The compiler will frequently generate calls to create these PyObject
structures (often storing the result in a variable), and also pass
these PyObject structures back into the runtime as needed.
This isn't a bad approach, but why did they use non-portable COM
to implement this? They should have been able to use PInvoke() to
directly access the Python data structures. It would be far more portable
> because the CLR isn't well-suited to dynamic languages
Could you elaborate what you mean? Some usages of types can be
inferred, but for the general case, couldn't the following table-driven
class take care of the problem?
delegate void MemberFunction(object arguments);
object addFunction(string functionName, MemberFunction
object dispatch(string functionName, params object arguments);
> -- and oh sorry,
> version 2.0 will probably break all those other languages, and at that
> point you'll just give up and write C# and VB code.
Could you elaborate? Looking at the template and functional additions to
the CLR, I don't see any reason why this would be the case.
More information about the Python-list