[IronPython] Some thoughts on namespaces, extension methods
fuzzyman at voidspace.org.uk
Tue Nov 18 12:55:14 CET 2008
Dan Eloff wrote:
> 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.
Hmmm... the topic has been discussed by the Python developers in the
past, and there is a pretty solid consensus that being able to modify
the built-in types is 'crazy'. I think you would find that a significant
proportion of the community would believe that allowing the modification
of built-in types is not Pythonic and that IronPython was changing
Python if it allowed this.
Brushing aside Guido's concerns as FUD (even if you disagree - and I'm
agnostic on this particular topic) is unlikely to be seen as a valid
argument either... I don't think that this is an implementation detail
of CPython but a conscious decision (although performance of attribute
lookup and memory savings for the built-in types as each instance
doesn't require an instance dictionary are likely to be part of the
reason for this implementation decision in CPython - but by no means the
Although monkey patching has been beloved in the Ruby community there
has been interesting push-back in recent months.
Extension methods in C# are an interesting language feature. This is one
area where static-typing is helpful as you can get early warning of
incompatible extensions (and with method overloading can even multiple
extension methods with the same name but different signatures I guess).
It would still be a *problem* if you wanted to use two libraries that
both tried to extend types using the same extension method names, but at
least you would get warned about it rather than simply having runtime
> 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.
> Users mailing list
> Users at lists.ironpython.com
More information about the Ironpython-users