-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of drew moore Sent: Sunday, February 18, 2007 8:25 AM To: Discussion of IronPython Subject: Re: [IronPython] Method invocation when assigned to instancediffers from default assignment?
Wow! you're not the typical Python newbie! --Reply-- Indeed. The entire team is relatively new to Python, or any high level scripting language for that matter. All the programmers, like me, are more used to the complex languages like C/C++, C#, and Java. We reviewed several scripting languages we could embed, and decided to use Python. Now I need to catch up on Python as I modify the interpriter. -----Original Message----- I don't know much about Fibers and Interruptible IronPython, but it sounds very interesting. --Reply-- It's not surprising you don't know about "Interruptible IronPython" (working name), as it is propriatary at the moment (It's also nowhere near finished). I mentioned it tangentially when I started working on it, in the e-mail "Suspending, saving script execution?". Basically Interruptible replaces MSIL with an interpriter that allows the application to suspend a script wherever it wants (after so many commands, so many milliseconds, and/or manually) so that the thread can continue its execution. It is also serializable, so the data and instruction pointer can be saved and reloaded exactly where it was. IronPython /w Fibers is the method we used in our prototype. IronPython was left entirely unmodified. The only difference from what one usually does is that the hosting application puts each script into its own fiber (http://msdn2.microsoft.com/en-us/library/aa450744.aspx), which is basically a manual thread. The application then pauses the fiber whenever a function takes time (multiple frames) to finish. I knew this was a poor solution when I chose it (no saving/loading, a hard limit to the number of scripts that can be run at a time, malformed scripts can block execution, etc), but we needed to get a prototype done and the limitations were acceptable within the prototype. But that's why I, a Python 'n00b' am modifying IronPython. -----Original Message----- Here's a simple scenario I can think of where instances might have callable attributes that don't need (or want) self automatically put in as the first argument: --Reply-- But see, wouldn't it be nice, in your example, to do this: import sys class Logger(object) : writer = sys.stdout.write def __init__(self, writer=None) : if writer is not None : self.writer = writer def Log(self, message) : self.writer(message) Temp = Logger() OtherTemp = Logger() ErrorLog = Logger(sys.stderr.write) #At a later point in time... messageCount = 0 def myLogger(message): global messageCount messageCount += 1 sys.stdout.write("<" + str(messageCount) + ">" + message) Logger.writer = myLogger Temp.Log("SomeMessage") OtherTemp.Log("SomeMessage") ErrorLog.Log("SomeError") As neither Temp nor TempOther have their own instanced function, Log would have to fallback on the class function, which is now different, just like any other class variable. But we can't do that as a function attached to a class is considered an unbound method. This inconsistency is what has me confused about the utility of this ability. _______________________________________________ users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
