Interesting points... we do currently share types for built-in types between objects. But we could still have per-ScriptRuntime extensions for them. We actually support this today w/ our ExtensionTypeAttribute (which you could use to do this but you'd need to write the extensions in C#). But doing it for user defined members would be a bit different but certainly not out of the question.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Eloff Sent: Wednesday, November 12, 2008 3:40 PM To: Discussion of IronPython Subject: Re: [IronPython] Some thoughts on namespaces, extension methods On Wed, Nov 12, 2008 at 4:19 PM, Dino Viehland <[EMAIL PROTECTED]> wrote: > Actually I'd say modifying built-in types is unpythonic - for example you > can't do object.xyz = 42. We could choose to break this rule for types we > don't share between Python & .NET, and it probably wouldn't be a lot of work, > but I'm hesitant to have the two sets of types treated differently. I'm going to be contrary here and say that modifying built-in types is not allowed by the current C implementation, but is compatible with the language and principles that define pythonic. To paraphrase Guido, there are two main reasons why modifying builtins is disallowed. 1) To prevent accidental breaking of unrelated code in unexpected ways. 2) Since builtins are shared between interpreters running in the same address space, making them mutable would allow code in one interpreter to affect the other. The first seems to me an extension of the ancient argument that you should not be trusted with fire because you might burn yourself. It's a fud appeal, not an argument. The second is a very real concern. Would changes to namespaces, static classes, monkey patching types etc be visible across what should be isolated script engines? It doesn't have to be that way, but like CPython we might well decide the perfomance/complexity tradeoff involved in isolating mutable types is not worth it. Essentially this is an implementation artifact of CPython, and like reference counting or the GIL, it is not something that IronPython has to copy. I'm interested what people have to say about this. -Dan _______________________________________________ Users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
