much faster than C#.
Without expending any effort actually working it out, my guess is that because IronPython uses reflection so heavily it caches the reflection lookups - and it is this caching that is giving it the performance benefit. Reflection on .NET is not fast, by any stretch of the imagination, and improving the performance of reflection would make a big difference to speeding up DLR languages.
The Silverlight Toolkit is an open source project by Microsoft providing additional controls for the Silverlight browser plugin. By releasing them as an open source add-in it reduces the size of the initial plugin download (at the cost of increasing the size of applications that use them), but also means that they can also be used directly in Moonlight (the Mono version of Silverlight for Linux that went into beta a few days ago) without having to be re-implemented.
The toolkit is divided into five 'bands' offering different ranges of controls. The bands are mature, stable, preview and experimental. The controls in the mature band alone are:
Python Package Index (PyPI - the Python equivalent of Perl's CPAN). The project page says:
Modules for use with IronPython.This doesn't really tell us a lot. The pycopia homepage says:
The purpose of the modules here are to enhance the IronPython runtime with extra modules for debugging and better integration with the rest of the Pycopia framework.
The Pycopia project is a framework of frameworks for the rapid development of applications related to telecommunications networks, web, data processing, process control, and more.Entity framework profiler with integrated IronPython scripting. In this blog entry he ponders what to do when there are both Python libraries and .NET libraries available for a task in IronPython. Even with basic things like file I/O and threading you have a choice whether or not to use the standard Python idioms or .NET libraries. They have slightly different semantics of course but it is often not obvious which is a better fit.
Simon also describes his strategy for learning Python and IronPython:
To help myself form my own opinions I decided that the best learning path for me was as follows:dynamic keyword, and of course with IronPython. The post includes some interesting details on writing dynamic objects implementing IDynamicMetaObjectProvider that can be used from all these different languages. IronPython in particular it seems needs some special treatment because of the way BindGetMember is called instead of BindInvokeMember.
Some people will surely think that points 2 and 3 should be reversed? Perhaps, but my rationale for taking this approach is that Python is not likely to become a daily instrument in my work and I want to understand as much as possible about it in the .NET world first. I do believe however that to truly understand the power of Python I will need to learn deeply about its roots and oddly I suppose that step in the process will come last.
- Read the Python 2.5 (CPython) documentations PDF Tutorial and re-type it’s code examples and follow with my own experimenting. This allowed me to get a fairly good overall feeling for the language.
- Read IronPython in Action to get a good overall point of relevance to .NET and see how the power of .NET as a platform would impact the Python experience and visa versa.
- Read Python in a Nutshell and get a grasp on Python’s roots and how the language is best put to use on it’s original platform (the C implementation).
- Compiling IronPython and IronRuby
We have just updated ToolsVersion attribute in .csproj files included in IronPython and IronRuby solutions to "4.0". This change will soon show up in CodePlex and GIT sources.
It allows to open these projects in Visual Studio 2010 (using IronPython4.sln or Ruby4.sln). The binaries produced by both builds (from VS2008 and VS2010) still have dependency only on .NET 2.0 assemblies so there is no change in that.
You'll need Service Pack 1 installed in order to build Ruby.sln or IronPython.sln from VS2008. When you build from VS2008 you'll get a bunch of msbuild warnings:
Project file contains ToolsVersion="4.0", which is not supported by this version of MSBuild. Treating the project as if it had ToolsVersion="3.5".
This is expected, you can ignore them.