[IronPython] Some thoughts on namespaces, extension methods

[Dino Viehland]

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: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] 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 <dinov at microsoft.com> 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
Users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com