[IronPython] Some thoughts on namespaces, extension methods

[Michael Foord]

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 
only reason).

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 
madness.

Michael

> 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
>   


-- 
http://www.ironpythoninaction.com/