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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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: pass 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 <[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>> 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, http://www.network-theory.co.uk/docs/pytut/CompiledPythonfiles.html In 1.0, there was a sample of how to do this: http://www.codeplex.com/Release/ProjectReleases.aspx?ProjectName=IronPython&ReleaseId=423 However, at the moment this is not supported in 2.0 (http://lists.whatwg.org/pipermail/users-ironpython.com/2008-February/006507.html) Ben On Wed, May 14, 2008 at 4:13 PM, Ben Aurel <[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>> 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 > [email protected]<mailto:[email protected]> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ Users mailing list [email protected]<mailto:[email protected]> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- ___________________________ Matthew Barnard
_______________________________________________ Users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
