On 4/21/05, Keith J. Farmer <[EMAIL PROTECTED]> wrote: > Nonetheless, it does present some basis from which to start. > > I also suspect, specifically regarding the Starkiller paper, that some > of the problems aren't all that relevent. For example, dynamic method > creation: is that something that is going to be exposed outside of > IronPython? If not, then do we need to worry about it? If so, such as > a callback defined through some hosted scripting environment, then > perhaps we say that callbacks must be unambiguous about their type. I'm > willing to suggest that all such reference types must be strongly typed. > Strings, numbers, and other primitives should be fairly simple > otherwise.
Sure, you could do that and gain performance; however, python favors simplicity over such a solution. Very specifically IronPython is meant to implement Python and not change the language. So basically IronPython is not going to do this. If you take this philosophy and apply it to python as a hole, you end up with a type inferenced python; you end up with something like Boo. So while IronPython isn't going to implement this, there exist an easy avenue to do what you're asking for. So I'd suggest you give Boo a look if that's what your looking for. (Previous discussions have suggested Boo as a nice python-like way of writing statically typed code instead of C#, and then have python call out to that instead) _______________________________________________ users-ironpython.com mailing list users-ironpython.com@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
