[IronPython] Method invocation when assigned to instancediffers from default assignment?

Erzengel des Lichtes erzengel-von-licht at cox.net
Wed Feb 21 01:56:49 CET 2007


-----Original Message-----
From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] 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.





More information about the Ironpython-users mailing list