The biggest problem we had with IronPython originally was probably the fact
that I was the only developer on the (very small) tools team that was familiar
with Python beyond the fact that it uses whitespace for control flow :)
Other than that, though, the biggest things we ran into:
1. We noticed some odd discrepancies in our programs' runtime when running
inside of the debugger versus out of the debugger. Specifically, we have a
single line of IronPython that calls a single line of C# code that calls a
single P/Invoke into our native code. This native code loads the content data
for the game. When we launch the IronPython process from VS2010 with the
debugger, then it takes upwards of 10 times as long to execute the native code.
When we launch it with Ctrl+F5, then it operates at normal speed. I'm not sure
what could be causing this, since the speed issues are happening in the native
code, but I do know that launching our C# application that calls the same
P/Invoke into the same native code (same build, same file, etc.) then there's
no discrepancy between launching it inside of our outside of the debugger.
2. Debugging the IronPython code was difficult. If it was at the top-level of
the file, then we couldn't inspect variables, step into some lines, etc. If we
made a function at the top level and then called into it immediately, then we'd
have the debugging utilities fully available. Don't know what's up with that.
3. There was a weird bug that I could reproduce with smaller code, that I can
only attribute to IronPython. We had two larger functions that didn't depend on
each other or mutate any shared state, etc.. Each of the functions fires off
exceptions down in the stack and catches the exceptions. BUT, when I called one
of those functions before the other one, it seemed like it broke the exception
catching functionality. What I don't get is how this would be possible even if
I were trying to break it in the same way. I would throw an IronPython defined
exception directly inside of a try catch block that catches any CLR exception,
or any exception, or anything, and it wouldn't catch the exception. The
exception would bubble right on through and treat it as unhandled. At one point
I literally had the following code, and it would still not get caught:
try:
raise Exception()
except:
print "Test"
Test wouldn't get printed, the Exception would take down the program the normal
way. I spent a whole day looking into this, and couldn't figure out what was
going on, so I gave up and left the two functions in the order that they were
in when it was working, and it kept working.
4. The TryInvokeMember/TryGetMember weirdness for methods
(http://lists.ironpython.com/pipermail/users-ironpython.com/2010-June/013104.html)
is more weird than it lets on. I don't remember the details, but it was
something like if the method was called with no parameters then TryGetMember
was called first, otherwise it would call directly into TryInvokeMember. This
meant that most of our code worked fine (we didn't cover the TryGetMember case
at all) until we tried to write a function that didn't take any arguments and
call it from IronPython; it didn't work and for apparently no reason (until we
discovered that it made sense that it would call TryGetMember first).
5. I understand why the RuntimeBinderException occurs, but it's a really big
annoyance to try to develop an application that calls over into IronPython code
through DynamicObjects repeatedly. I wish we could decorate a class in such a
way that it would just assume that all calls need to be reflected/whatever, so
that it wouldn't fire hundreds of RuntimeBinderExceptions at the startup of our
application (we were doing scripting from C# using the 'dynamic' keyword here.)
We would always have to remember to turn off first-chance exceptions for that
one, etc., in our otherwise first-chance exception free development environment.
These are the only things that came to mind when thinking of what we ran into
when using IronPython; we've been developing with it for probably 6 months now
(we've always used 2.7A1) and now ~40 game developers use our tool full-time to
get the game built. :) As the article mentioned, we have some designers writing
Python scripts to generate content, mutate existing content, link it together,
etc., and it's a pretty awesome time-saver.
On a side note, it seems like IronPython could be enhanced to provide a better
Python learning experience for new programmers. For example, it would probably
be pretty easy to detect that you have used a function as a statement, like by
Console.WriteLine on its own line without parentheses, and offer optional
warning levels to help detect cases like this. :)
Daniel Jennings
-----Original Message-----
From: Jeff Hardy [mailto:jdha...@gmail.com]
Sent: Monday, March 14, 2011 6:22 PM
To: Discussion of IronPython
Cc: Daniel Jennings
Subject: Re: [IronPython] ArenaNet's Use of IronPython
That's awesome. I think it might be time to start a "Who's using
IronPython" page somewhere.
The upgrade to 2.7 should be pretty seamless, BTW. Is there anything
that you're missing? Anything that would make your use case easier?
- Jeff
On Mon, Mar 14, 2011 at 3:30 PM, Daniel Jennings <dani...@arena.net> wrote:
> Just thought I'd share with you guys an article that among other things
> discusses how we at ArenaNet are using IronPython. We don't go into many
> details about how important IronPython is to our editor, but we at least
> allude to it. Every time Python is mentioned it's using IronPython J
>
>
>
> http://altdevblogaday.org/2011/03/13/before-you-wreck-yourself/
>
>
>
> Let me know if you have any questions about the boring details! We're
> currently using 2.7A1, but that's only because we haven't taken the time to
> make sure that we're immediately compatible with the later versions J
>
>
>
>
>
> Daniel Jennings
>
> _______________________________________________
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
_______________________________________________
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
