@rndname
The fantastic thing about IronPython is that you get *two* standard libraries – both the Python standard library *and* the full range of .NET libraries.

Yes Python is a highly dynamic language – and you lose none of that dynamism by switching to ironpython. Introspection works just as you would expect – and in fact needs to in anything calling itself an implementation of Python. In IronPython 2.6 Python stack frames (which Guido himself has called an implementation detail) even work. Pdb works as well (*and* you can use .NET debugging tools).

With a tool called Ironclad you can even use many Python C extensions with IronPython.

In addition to the excellent standard library, *real* Python is an extremely dynamic language. It allows you to implement anything from distributed programming framework, code migration libraries and full-blown debugger for the language itself. Everything by using pure Python and nothing more. (If you say that in .NET people should use .NET debugger, you totally lost the point.) But you can’t even use sys._getframe() in IronPython. Probably I should not even ask about changing the bytecode of functions on-the-fly.

Giving up some of the reflection and dropping the low-level runtime modifiability would kill the Python even if the standard library would work perfectly. Those things make real Python one of the most powerful dynamic languages there is.

The best syntax and semantics do not make the best programming language alone. It also takes the best runtime and the standard library, too.

Most of the standard library and huge swathes of the libraries on PyPi *do* work, so your argument is mainly moot anyway. You claim you can’t ‘download and use eggs’ but that is basically untrue (unzip them and add their directory to the path).

I assume you think Jython isn’t Python either?

You are hopelessly confusing Python the language with Python libraries. You can’t use Python libraries that depend on Linux functionality on Windows – and vice versa. By your rules Python isn’t Python as there are plenty of libraries that don’t work on any specific platform!

VB.NET *isn’t* very dynamic and if you like Python and want access to functionality in the .NET framework, IronPython is a fantastic implementation of Python.

You can’t run Python code and run it in IronPython unless you stay clear of any modules either those missing from the standard library or pypi, you can’t pip or easy_install things around, nor you can run IronPython code in Python that uses any .net libraries. Your project is basically married to either one platform or the other.

You can’t download an run eggs so you can’t say “I can run python” with only IronPython installed.

So the only good reasons for IronPython are because you needed a dynamic language and dynamic VB.NET did’t cut it or you want to provide scripting and are adamant python is the way to go. (Or just because)

Now, there is a Python like language that allows you to ignore types if you want, and has type inference for when you need it, it is way easier to adapt to C#/VB.NET and has some extra features, its called Boo.

Now since IronPython is hopelessly incompatible with Python, why not using Boo? I just don’t see the appeal. But don’t worry we just agreed I’m wrong…

Nonetheless interacting with dynamic objects from C# can easily be done. See this article for some examples:

http://www.voidspace.org.uk/ironpython/hosting_api.shtml

IronPython in Action is an even better reference on this subject…

Michael Foord