Limitations of Python for .NET

In this section, we devote some space to the limitations on the Python for .NET system.

Performance

Probably the biggest single issue with Python for .NET is the performance of both the compiler and the runtime. The speed of the runtime system must be the more critical issue, as the fastest compiler in the world would not be used if the generated code is too slow to be useful.

Only a small amount of effort has gone into analyzing the performance of the runtime system, mainly due to the lack of (free or cheap) performance analysis tools available for .NET. Without such tools, making performance- related changes is fruitless, as their effectiveness is difficult to measure.

Not withstanding the tuning of the runtime system, the simple existence of the runtime accounts for much of our performance problem. When simple arithmetic expressions take hundreds or thousands of Intermediate Language (IL) instructions (via the Python runtime environment) to complete, performance will always be a struggle.

We discuss type-related performance in more detail later in later sections.

Closed World Syndrome

Competing for the title of biggest single issue would have to be interoperability with existing Python code. Python itself is a very simple language, deriving much of its power from its library. Although the standard library (the modules provided with Python) is very rich, it is the vast array of extension modules provided by third parties that really provide the power. Indeed, most Python books and Internet queries relate to using various modules, rather than the language itself.

The existing Python for .NET system does not allow any leveraging of existing Python code. Although much of the standard library can be ported to .NET, it would not be reasonable to attempt to cover every Python module available.

Although .NET has its own rich class library, it does not solve the problem. There is not 100% overlap between the .NET and Python libraries, and lots of existing Python code already exists that references these various external modules ”module dependencies often run quite deep.

Class and Instance Semantics

Although support for basic classes works fine, there are a number of areas where Python and .NET semantics collide ”the most obvious being multiple inheritance (supported by Python, but not by .NET). Other, more subtle examples include the ability of a Python subclass to avoid calling a base-class constructor or to reference self (the moral equivalent of this in C#) before calling any constructors at all.

Unfortunately, many of these semantics are used regularly in Python programs, so simply not supporting them in Python for .NET would raise a significant compatibility hurdle .

It was apparent that the existing simple design would not support the required semantics, so no attempt was made to extend it as far as needed. However, with a clever design of the Python for .NET class system, and borrowing from Jython, it should be possible to get a very close match to the defined Python semantics.

Type Declarations or Inference for Speed

Python code does not have type declarations. However, all Python objects have a distinct type, so Python is not a typeless language. As an example, consider the following two Python statements:

 a = "hello"  a = 7 

Although the Python variable a has not been declared, after the first statement it references a Python string object. After the second, it references a Python integer object. At any point in time, the variable has a specific type.

As a result, the compiler is rarely able to generate efficient code. The compiler makes no attempt to track variable assignments and types, so it always generates code for the general case. Thus, simple arithmetic operations take many orders of magnitude more Intermediate Language instructions (including calls into the Python for .NET runtime system) than would be required if the types of the variables were known.

There are two general approaches to this issue ”type inference and type declarations. Type interference would involve the compiler tracking assignments and the types of objects. Although good results would be possible using local analysis, the dynamic nature of Python and the modular compilation unit would prevent this approach from working completely effectively. Type declarations would involve explicit declarations or other hints being added by the user . However, Python does not define syntax for these features.

Type Declarations for Semantics

There are certain situations where type declarations are required to capture certain .NET semantics rather than for speed reasons. The most obvious example is method overloading ”the ability to define a class with multiple methods of the same name , each differing in terms of the number or types of parameters. As Python does not support type declarations, it has no way to express such constructs. Therefore, some syntax ^[5] was invented to allow expression of overloaded methods.

^[5] Technically, it is not a syntax change ”the compiler recognizes assignment to a specially named variable and reacts accordingly .

Although this is an adequate workaround for Python implementing overloaded methods and functions, it does not provide the facility to nominate the overloaded method when actually making a call. For example, given the Python statement

 myobject.Foo(a) 

and the fact that Foo is an overloaded method, the compiler has no way to determine the correct function to call, nor does the user have the ability to nominate it. In this situation we rely on .NET reflection to select the appropriate function at runtime, but this has performance implications and simply does not work when attempting to call base class methods or constructors.