Mono and Python

[Mark Hammond]

Robert N. Deviasse wrote:

> 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
> and efficient.


I think you misunderstood.  The IPyType is not an interface to a CPython 
  PyTypeObject object.  It is a .NET reimplementation of the 
PyTypeObject semantics (actually implemented in C#).  Thus, there is 
nothing COM (or even MS specific I am aware of) in the runtime.

As you quoted above (and I snipped) the compiler itself *does* use COM.

For anyone looking at running Python on the CLR, I think an early 
decision needs to be made - do we try and go "native CLR", or build a 
"CPython interface".

The project you refer to uses the "native CLR" approach, and I believe 
is basically what Jython does.  There is no CPython runtime involved, 
and all C implemented modules need to be reimplemented somehow.

The "CPython interface" approach would build bindings to the existing 
CPython.  This would allow many existing modules to be used as is.  This 
may however offer less then perfect integration, but Python 2.2 
type-class unification efforts may make this more tenable.

Mark.