[IronPython] 2 Basic question about IronPython and dyn. langs in general

Dino Viehland dinov at exchange.microsoft.com
Wed May 14 22:10:12 CEST 2008

Yep, the additional code is all there to deal with the dynamic typing.  There's another significant difference though and that's when you declare classes.  C# will generate a class exactly like how you specifiy it but IronPython will generate a subclass of whatever your base type is, it will override all of the virtual methods on it, and then turn any of those invocations into a lookup in a dictionary and an invoke of the resulting member.  The actual generated class won't contain any of the members you define and it also won't have a parameterless constructor.  That breaks certain scenarios where tools expect to find the real class or expect to be able to create instances of some class.  Ipy studio contains some code to be closer to C# but it's one big hack.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Matthew Barnard
Sent: Wednesday, May 14, 2008 11:48 AM
To: Discussion of IronPython
Subject: Re: [IronPython] 2 Basic question about IronPython and dyn. langs in general

First, I would like to ask anyone with more experience than myself (which is not much) to comment on the validity of this test.
I'm sure there are multitudes of differences I am not aware of that would make these results misleading.

2) IronPython Studio does indeed compile ipy code to MSIL, though I'm not clear on how.
The executable generated by IPy Studio contains MUCH more code than the C# exe.

Comparing a for loop between IPy and C# leads me to the following:
Because python's for loops are actually foreach loops (for i in list), I am using a foreach loop in C# as well.
Also, because C# has no native type akin to a python list (list resembles a List<> more than anything),
I am using List<int> for both, and iterating through it. I have initialized each List<> outside of the test() method
and added [0,1] to both.

static void test()
    foreach (int i in lst)

def test():
    for i in lst:

The MSIL for the C# can be seen at http://www.nomorepasting.com/getpaste.php?pasteid=15742&seen=true&numbered=on
and the MSIL for the IPy can be seen at http://www.nomorepasting.com/getpaste.php?pasteid=15741&seen=true&numbered=on
both showing instructions only and with proper wrapping.

Counting instructions only, the IPy generated 14 instructions more than the C# in order to achieve what, in a practical situation (as in, how you would actually use each), is the same code.

Looking at the bigger picture, however, the difference in generated bytecode between the C# application and the IPy application is VAST. Again, in a practical sense, both are written in the same manner. That is, if you were to write two applications to accomplish the same task, this is typically how it would be accomplished. It is clear to see that the standard bare-bones C# application produces far less bytecode than the standard bare-bones IPy application.

Please, correct me if I'm wrong. This is the extent of my knowledge.

On Wed, May 14, 2008 at 8:56 AM, Ben Hall <ben2004uk at googlemail.com<mailto:ben2004uk at googlemail.com>> wrote:
I'll try to do my best to answer this.

1) Because a large is dynamically typed, doesn't mean you can't do any
verification on the code. Michael Foord told me about PyFlakes
(http://divmod.org/projects/pyflakes) and PyLint
(http://pypi.python.org/pypi/pylint) which can do static analysis on
the code to identity protential problems.

2) If by native code you mean something like C++, then I expect so.
Most languages are slower than C++,  and it comes down to CPU cycles
vs Developer Cycles. I'm sure developers are much more productive in
Python than C++.  Guess it depends on your application, but Python is
running on lots of high performance systems so I don't really think
its a problem.

3) Not sure if I understand your question. You can compile Python into
bytecode.  Compiled Python code are .pyc,


In 1.0, there was a sample of how to do this:

However, at the moment this is not supported in 2.0


On Wed, May 14, 2008 at 4:13 PM, Ben Aurel <ben.aurel at gmail.com<mailto:ben.aurel at gmail.com>> wrote:
> hi
> I have two questions on two different subject but anyhow connected. Also I
> have to admit that I could probably find the answers myself. But I'm quite
> new to all that things and I have a lot to catch up to...
> If I understand correctly the are 2 main advantages when it comes to dynamic
> languages:
> + Objects doesn't have to be typed be the developer
>   (saves time, makes code shorter and better readable code)
> + Code is interpreted
>   (no compilation step during development, source dont have to be compiled
> for the target machines before deployment)
> which implies the 2 following disadvantages
> - Writing a lot of tests to catch potential runtime errors (no compile time)
> - Slower than native code
> Questions:
> 1. Why belong the terms "untyped" and "interpreted" somehow together? Why
> can't the type inference that has to be done at runtime  not be done at
> compiletime. I think the runtime interpreter has to compile the python
> bytecode to native code somehow - no?
> Why isn't there a possibility to *compile* python/ruby/perl/... code to
> native code at the first place?
> 2. I've read about, that it is possible to compile Python Code to msil with
> IronPython. Unfortunately I'm not yet at the point where this run on my
> machine (macosx). So I do have to ask you: Is such a dll/exe the same as I
> would compile it from c#? Does similar language constructs (eg. for loop,
> class object creation) the same performance?
> Thanks in advance.
> Ben
> One of the list members - Ben Hall - pointed me at one of his blog posts
> [1].
> http://blog.benhall.me.uk/2008/05/ironpython-classes-within-separate.html
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com<mailto:Users at lists.ironpython.com>
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Users mailing list
Users at lists.ironpython.com<mailto:Users at lists.ironpython.com>

Matthew Barnard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20080514/2efbd70e/attachment.html>

More information about the Ironpython-users mailing list