[IronPython] Some thoughts on namespaces, extension methods

Dan Eloff dan.eloff at gmail.com
Thu Nov 13 00:40:03 CET 2008

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.


More information about the Ironpython-users mailing list