Possible .NET and Python Enhancements

As can be seen from the previous section, there is still plenty of work to be done before we take full advantage of .NET given the current state of both .NET and Python. Therefore, we limit this section to a brief discussion of the possibilities and save further analysis for when the existing implementation could be considered of usable quality.

Type Declarations

There has been discussion in the Python community about adding optional type declarations to a future version of Python. However, for similar reasons as outlined here, no consensus has been reached, and no concrete implementations have been delivered. If Python ever does gain such capabilities, it is expected that there would be support for all of our type declaration requirements ”both declaring the signature when implementing a method and selecting which signature you wish to call.

Once we have syntactic support, the compiler will need to be enhanced to take advantage of the declarations. Indeed, this is probably the biggest issue preventing Python from moving forward with concrete syntax proposals. It is still not clear anyone has the time or inclination to enhance the CPython runtime system to take full advantage of them, so the syntax enhancements would be pointless. If a commitment from the Jython or Python for .NET projects is made to support these enhancements, it may help accelerate the acceptance of these proposals into the Python language specification.

Dynamic Language Support

Due to Python's dynamic nature, there are some Python features that are difficult to map into .NET semantics. A simple example is the ability for a Python object to add attributes at runtime ”although no declaration or other reference to the attribute can be seen by source code analysis, reference to the attribute will succeed at runtime. Python provides many other ways to change object behavior at runtime that are not captured by .NET.

To support this capability, the compiler will often emit special symbols or code specific to Python. At runtime, if these features are found, they are used; in this way, Python can take advantage of these features. This allows Python code compiled in a separate compilation unit (that is, a unit that exists in a separate assembly) to still provide these dynamic Python semantics when the caller is Python.

This dynamic capability is analogous to IDispatch support in COM ”the ability for a language to dynamically determine or expose an object model at runtime. .NET leans much more toward compile-time determination of these attributes, in a clear drive for speed. However, the very nature of Python and scripting languages in general is that their users have made a conscious decision to trade execution speed for these runtime features ”although possibly not as much execution speed as Python for .NET is currently costing them.

It is clear that such dynamic features may preclude use of certain other .NET features. For example, the performance penalty associated with allowing dynamically created methods to be used as virtual methods may mean they are not supported as virtual. However, there is still enough utility in the feature overlap that would make this a useful, but optional .NET addition.

It should also be noted that there are many languages with dynamic features comparable to Python. However, with Python and every other such language needing to invent its own dynamic solution, these languages are not able to share such features, even when it would make sense to be able to do so. Formalization of these features in .NET would allow multiple dynamic languages to interoperate in a natural manner.